/ URBANBLUE RECORD OVHcloud incident archive

My public incident record / updated 17 July 2026

OVHCLOUD FUED US. THIS IS HOW FIVE YEARS
DISAPPEARED.

Our recovery architecture failed us. OVHcloud's explanation still does not add up.

Whole project terminated Support said: not related to payment Support said: our responsibility
Start with UrbanBlue Open the evidence

01 / WHAT URBANBLUE BUILT

THE FIRST PRODUCT DID NOT REACH REPEATABILITY. THE WORK WAS FAR FROM DEAD.

Before the invoices, the suspension, and the deletion, there was a serious, externally supported technical venture. Its engineering assets already had a next commercial use.

UrbanBlue AquaPulse composite showing annotated microbial microscopy, field hardware, an operator interface, and wastewater process analytics
UrbanBlue / AquaPulse platform visual Microscopy + field hardware + operator software + process analytics
Microscopy and microbial detection AquaPulse field hardware Operator interface Process analytics and historical trends

UrbanBlue was built to make wastewater treatment more observable.

Over several years, we developed AquaPulse: a combination of microscopy hardware, computer vision, machine-learning models, process analytics, and cloud software designed to observe microbial conditions inside wastewater-treatment systems.

The first commercial product did not become the repeatable business we had hoped for. I am not going to rewrite that history. But a product outcome is not the same thing as the value of the engineering behind it.

But UrbanBlue was not an empty company, and the work was not obsolete. Its value was not limited to one product or one company structure.

WHAT REMAINED

  • High-resolution microscopy systems for wastewater environments
  • Image-processing and microbial-classification pipelines
  • Annotated microscopy datasets and historical process data
  • Machine-learning models and experimental artifacts
  • Aeration, nutrient-balance, and sludge-condition indices
  • Dashboards and operator-facing software
  • Years of experiments, engineering decisions, and domain knowledge

THIS WAS NOT A WEEKEND PROJECT.

A serious technology venture, tested through external programmes.

UrbanBlue was developed through years of engineering, research, field work, and external review. It received grants, incubation, acceleration, or programme support through Government of India initiatives and recognised innovation organisations, including MeitY-supported programmes, NIDHI-PRAYAS, SINE IIT Bombay, Techstars, and Imagine H2O.

Their involvement does not prove every product claim or make commercial success automatic. It does establish that UrbanBlue was a serious, externally reviewed technology venture - not a prototype built over a weekend, not a speculative idea, UrbanBlue was a real engineering programme built over years.

THE WORK WAS ALREADY BEING BROUGHT BACK INTO PRODUCTION.

We had a purchase order and active written discussions for incorporating UrbanBlue's historical datasets, microbial intelligence, models, and process learning into another product. We had a working technical approach and a defined commercial requirement. This was not a vague future possibility.

When we returned to retrieve the data, trained models, experimental records, and supporting assets needed for that work, the expected Public Cloud project was not in the account view. At first, that looked like a loading or access problem.

The deletion did not erase a hypothetical future. It interrupted work that was already moving toward its next commercial application.

WHY ONE PROVIDER?

The concentration was a mistake. It was not random.

The original commercial model had not produced enough capital to maintain fully replicated, multi-provider operational infrastructure. We selected OVHcloud as our primary provider because it was a major European cloud company that publicly positioned itself around data protection, sovereignty, and trusted infrastructure. We believed a provider of OVHcloud’s size and positioning would have reliable billing, account-management and project-governance processes.

That assumption turned out to be wrong for us. We were wrong to treat provider reputation as a substitute for independent recovery. A simpler off-provider archival copy was still our responsibility, and we did not implement one adequately.

The next step should have been simple: log in, retrieve the datasets and models, and begin the integration. It was not.

02 / THE LOGIN

ONE LOGIN CHANGED THE ENTIRE STORY.

18 November 2025. We went back for the resources needed for the next product. The project was not there. For the next three days, I tried to understand what the hell had happened.

  1. 18 NOV / 01 I LOGGED IN.

    I was there to retrieve the historical datasets, trained models, experiment records, and supporting assets we intended to use in another product.

  2. 18 NOV / 02 THE PROJECT WAS NOT THERE.

    Not one missing bucket. Not one stopped virtual machine. The Public Cloud project itself was not where it should have been.

  3. 18-21 NOV / 03 I REFRESHED. THEN I REFRESHED AGAIN.

    My first assumption was that the interface had failed to load. I refreshed and checked again. Nothing changed. I kept returning because permanent loss still did not feel like a reasonable explanation.

  4. 18-21 NOV / 04 I OPENED ANOTHER BROWSER.

    I checked the account from another browser, then went through the billing view. From the 18th to the 21st, I was stuck in the gap between seeing that everything was missing and understanding what had actually happened.

  5. 21 NOV / 05 I OPENED SUPPORT.

    At 17:44 on 21 November, I opened ticket CS12897544. The request was blunt: the services appeared terminated, and I wanted access back.

  6. 22 NOV / 06 THEN THE ANSWER ARRIVED.

    Support replied that the project had been suspended on 3 September, deleted on 3 October, and could not be recovered. It was not a display problem. The project had already been gone for seven weeks.

The deletion happened on 3 October. I saw the empty account on 18 November. For three days, I kept looking for an explanation that was not permanent loss. Then Support confirmed it: five years of work had already been gone for weeks.
Open the ticket entry / 21 Nov 2025 ↗ Open Support's first explanation ↗

The 18 November access attempt and the three-day login sequence are my firsthand recollection. The 21 November ticket timestamp and Support's later suspension, deletion, and non-recovery statements are in the record.

03 / THE BILLING SEQUENCE

A BILL CAME BACK FROM THE DEAD. THE PROJECT DID NOT.

This is the billing sequence I want OVHcloud to reconcile. I am not going to guess which internal process produced it. Here is what the invoices and later notice say.

The record shows conflicting billing treatment. It does not let me diagnose OVHcloud's internal account state. That explanation has to come from OVHcloud.

04 / SUSPENSION AND DELETION

THE WHOLE PROJECT WENT FROM SUSPENSION TO PERMANENT DELETION.

These are the dates OVHcloud Support later supplied. I present them as provider-stated events, not as proof that the payment premise behind the workflow was correct.

THE NOTICES EXISTED. SO DOES THE QUESTION BEHIND THEM.

Automated suspension and deletion notices were sent. We did not intervene before the process completed while our email service was malfunctioning. That explains why we did not stop the process in time. It does not explain why OVHcloud's systems placed the project into that process in the first place.

  1. SUPPORT LATER REPORTED SUSPENSION

    Support said the service was suspended because of an existing debt.

    Open the dated moment ↗
  2. SUPPORT LATER REPORTED COMPLETED DELETION

    Support said the deletion task had completed and that the data was wiped in the process.

    Open the dated moment ↗
  3. THE FIRST EXPLANATION ARRIVED

    Support said the Public Cloud project had been terminated for non-payment and could not be recovered.

    Open the exact source moment ↗

This was not presented to us as the failure of one disk, VM, or storage volume. OVHcloud Support said the entire Public Cloud project had been terminated.

05 / THE CONTRADICTORY RECORD

THREE SUPPORT STATEMENTS. ONE PROJECT. NO COHERENT RECONCILIATION.

These are OVHcloud Support's words inside ticket CS12897544 - not mine. Open the redacted records and read the surrounding messages yourself.

I am not declaring these lines a legal admission; that is for counsel or a tribunal. I am saying that OVHcloud first blamed non-payment, later separated the issue from our payment, then described the recent issue as its responsibility. Claims later denied liability. Those positions still need one coherent explanation.

06 / WHAT DISAPPEARED

IT WAS NOT A DISK. IT WAS THE WHOLE DAMN PROJECT.

OVHcloud Support described a terminated Public Cloud project that could not be reactivated. What became inaccessible with it included object-storage buckets, virtual machines, model artifacts, experiment records, and the scientific corpus on which the system depended.

PROVIDER-CONFIRMED

Project terminated, deletion task completed, data wiped in the process, and project could not be reactivated.

INTERNALLY DOCUMENTED

Infrastructure categories, research programmes, dataset types, software components, and recovery topology.

ESTIMATED

Data volume, record counts, field-recollection work, reconstruction effort, and financial impact.

A BACKUP INSIDE THE SAME PROJECT IS NOT AN INDEPENDENT BACKUP.

I learned that in the most expensive way available. If your recovery copy shares the same administrative blast radius, it is not a recovery plan. Please learn it for free.
7-8 TB
proprietary scientific data
40-50
wastewater treatment plants represented
50-55M
raw microscopy images
~200K
expert-annotated images
~12M
soft-sensor time-series points
Years
of experiments, models, embeddings, and weights

These are UrbanBlue's internal scale estimates. They are not provider-confirmed quantities or adjudicated damages.

07A / MY FAILURE

I TRUSTED ONE PROVIDER TOO MUCH.

  • No sufficiently independent off-provider recovery copy.
  • Critical data and recovery copies shared the same administrative failure domain.
  • We did not intervene before the automated process completed while our email service was malfunctioning.
  • I assumed an entire project would not be terminated without an effective safeguard or recoverable escalation path.
Please do not repeat this. I already paid for the lesson.

07B / OVHCLOUD'S UNRESOLVED RECORD

MY MISTAKE IS NOT A FREE PASS.

  • Explain why the suspension and deletion workflow began.
  • Reconcile the conflicting billing treatment.
  • Reconcile “non-payment” with “not related to your payment.”
  • Define what “indeed our responsibility” referred to.
  • Explain what deletion safeguards, review controls, or reconciliation checks applied before permanent deletion.
The notices existed. The premise behind them remains unresolved.

OVHCLOUD'S POSITION

OVHcloud says we chose how to store the data and that backups, business continuity, and disaster recovery were our responsibility. On that basis, OVHcloud denied liability for the loss and related damages.
FAIR. MY MISTAKE EXPLAINS WHY THE LOSS WAS CATASTROPHIC. NOT WHY THE PROJECT WAS DELETED.

Our architecture explains the blast radius. It does not explain why the deletion process began under a payment explanation OVHcloud later contradicted.

08 / WE TRIED TO RESOLVE IT

WE COULD FIND OUR NAME IN THEIR MARKETING. WE COULD NOT FIND AN OWNER FOR THE INCIDENT.

Support. Claims. Legal. Startup Program. Regional inboxes. Named executives. Two formal notice rounds, delivered to four addresses across India and France. Some people replied and one person genuinely helped. None of those routes produced a coherent explanation or committed resolution path.

02 support and claims tickets
07 documented route types pursued
02 / 04 formal notice rounds / deliveries
00 committed resolution timelines
Publication-safe facsimile of an OVHcloud Startup Program lead's LinkedIn post naming UrbanBlue OPEN PUBLIC-POST FACSIMILE ↗

“KEEP AN EYE ON THESE COMPANIES.”

OVHcloud employees publicly named UrbanBlue as a Startup Program company and described our work as real-time AI-powered microbial analysis for industrial wastewater treatment. The posts were promotion, not a warranty. The contrast still matters.

  1. Support engaged: it supplied the initial explanation, later payment and responsibility statements, and the Claims handoff.
  2. One Startup Program contact genuinely helped: she took calls and helped us find a working Legal route.
  3. Legal acknowledged receipt: no responsible owner or committed timetable followed in the produced thread.
  4. Formal notices were delivered: two rounds reached addresses in India and France.
  5. The exported case now says Closed: Priority 4 - Low, with no visible closure rationale.

I am not attacking the employee who tried to help me. I am documenting the system that left both of us without a working decision path.

Open every route and response →

09 / THE OFFER AND THE END STATE

CLAIMS LATER PROPOSED €700 CASH. SUPPORT SAID THE PROJECT COULD NOT BE REACTIVATED.

Claims first denied liability and described compensation as a commercial gesture. On 12 February 2026, it proposed two options. Neither proposal was tied to an assessment of the deleted assets or the reconstruction work required.

What rebuilding would actually take

REBUILD THE CORPUS Credits cannot recreate field samples, expert labels, historical plant data, or lost model lineage.
  • Field re-sampling
  • Microscopy regeneration
  • Expert annotation
  • Time-series reconstruction
  • ML redevelopment and validation
Complete reconstruction record / IMPACT-02 ↗

The proposal figures are presented as recorded in the claims correspondence and may be disputed by OVHcloud. My reconstruction record is preliminary, and its line-item arithmetic is still being reconciled. This page therefore does not present its aggregate estimate as an adjudicated or final damages figure.

JULY 2026 EXPORT

STATUS: CLOSED Ticket metadata shows an update on 18 May 2026. The export does not identify who closed the case, the exact closure time, or a closure rationale. I therefore do not present “Closed” as a reasoned final decision.
A blue and gold sunset over the sea, photographed during the founder's June 2026 trip
June 2026 / after the private routes had run out

I had spent months trying to keep this private. At this sunset, I decided the record had to become public.

10 / WHY I BUILT THIS

I TRIED TO RESOLVE IT IN PRIVATE. THEN I DECIDED TO MAKE THE RECORD PUBLIC.

I took these photographs on a June 2026 trip after a brutally hard year. I was trying to enjoy the sunset and not think about OVHcloud. One question would not leave me alone: after months of private escalation, what exactly was I still waiting for?

The loss was not newly discovered. The deletion wasn’t new. The silence was. What changed was that the record had stopped moving. Support, Claims, Legal, Startup Program contacts, executive outreach, and formal notices had produced no coherent reconciliation and no committed resolution path. The exported case now said Closed.

Before speaking publicly, I needed to do the part that had to come first. I accepted that our recovery architecture was inadequate and that we failed to intervene before the automated process completed. I rebuilt the chronology, redacted the source records, and separated OVHcloud's statements from our own estimates and conclusions.

WHY NOW?

Because waiting had stopped producing answers. Because every reasonable private route had been tried. Because silence was beginning to make an unresolved incident look resolved.

Publication was not the first step. It was what remained after the private process had run its course.

I could not buy equal power. Fine. I could build a public record that nobody had to take on faith.

So I am publishing now. Not because the anger is new, and not because I expect a website to replace a legal process. I am publishing because the private process exhausted itself while the central contradictions remained.

This is not a court judgment, and I am not asking for a mob. I am asking people to inspect the documents, other founders to learn from our mistakes, and OVHcloud to provide the coherent explanation the private process never produced.

- Akash Singh, founder
An intense orange sunset over the sea with a fishing boat in silhouette
June 2026 / the same trip / the moment waiting stopped making sense
I AM NOT ASKING FOR SYMPATHY. I AM ASKING FOR ACCOUNTABILITY.

11 / THE DETAILED RECORD

THE STORY STOPS. THE NERDY, CLICKABLE RECEIPTS BEGIN.

I moved the outreach ledger, 54 dated moments, and source register onto one page. Each timeline citation opens only the page or pages supporting that moment - not an entire ticket followed by a scavenger hunt.

  • ST-01 and the Claims ticket are released only as moment-specific page extracts.
  • The 77-page second-notice bundle is reduced to the actual six-page notice; duplicated exhibits remain separate.
  • The WhatsApp messages are withheld to protect the other participant's privacy.
Open the evidence page →

12 / RIGHT OF REPLY

OVHCLOUD: IF I GOT SOMETHING WRONG, SHOW ME.

Identify the sentence. Provide the supporting record. State the correction. I will publish a substantive, documented response next to the claim it disputes - not bury it in a footnote and not rewrite history to make myself look better.

Dedicated reply route: akash.singh@urbanbluetech.com . A substantive response from a verifiable OVHcloud address will be published in full or linked beside the disputed claim, subject only to necessary privacy redactions.

PUBLIC LOG / 17 JUL 2026

The homepage now records UrbanBlue's external support history, the next commercial use that triggered retrieval, the reason OVHcloud became the primary provider, and the exact notice-accountability distinction. A new discovery chapter records the login that revealed the loss, and the final chapter makes clear that I am still building.

13 / WHAT REMAINS

I STILL BUILD.

UrbanBlue's first product did not become the repeatable business we hoped for. The cloud project is gone. The work, the lessons, and the impulse to build are not.

I still believe industrial AI has enormous potential. I still believe difficult physical systems can become more observable, more efficient, and more sustainable through better engineering.

This record exists because I refuse to pretend this incident never happened. It also exists because I refuse to let the incident write the ending. I hope OVHcloud eventually provides the explanation I spent months asking for. Whether it does or not, this record will remain public.

THE PROJECT WAS DELETED. THE BUILDER WAS NOT.