My AI-built app is down and I don't know why. What do I do first?

It is a weekday evening, or a Sunday morning, and your app is not working. Customers are emailing. The platform's support form says it aims to reply within a business day. And the strongest instinct you have — open the editor and start fixing — is the one that will cost you the most.

This is the sequence I would follow, written for someone who did not build the app line by line. It assumes nothing is set up in advance, because usually nothing is.

The one rule underneath all of it: establish facts before you change anything. An outage where you know what is wrong is a short problem. An outage where you have made four undocumented changes to an unknown state is a long one.

Minutes 0–5: is it actually down, and for whom?

Half of reported outages are not outages. Before anything else, three checks, all of which take under a minute.

Open your live site in a private or incognito window. This removes your session, your cached files and your logged-in state — three of the most common reasons something looks broken to you and to nobody else.

Then load it on a phone with wifi off, on mobile data. Different network, different DNS resolver, different route. If it works on the phone and not on your laptop, you have a local problem and your customers are fine.

Then ask one other person, ideally somewhere else. If you have a customer already emailing you, you have your answer and can move on.

Write down what you find in one sentence, with a timestamp: what is broken, for whom, since when. That sentence is the single most useful artefact of the entire hour, and it is the thing people skip.

Minutes 5–10: what changed?

Almost every outage has a cause that arrived recently, and the fastest route to it is chronological rather than logical.

Open your hosting dashboard and look at the deployment list. There is a timestamp on the most recent one. Compare it to when the problem started. If a deploy went out shortly before things broke, you are very probably done investigating and can skip straight to rolling back.

Then ask what else changed today that was not a deploy: a setting you toggled, a key you rotated, a plan you changed, a domain you moved, a package you updated, an integration you connected. In AI-built apps this list is longer than people remember, because changes are cheap and undocumented.

Also check whether nothing changed on your side, because that is informative too. An app that breaks with no change from you points outward — to a limit, an expiry, or a vendor.

Minutes 10–12: the status pages

Ninety seconds, before you look at a single line of your own code.

Check the status page of your host, your database provider, your payment provider and your email provider. Then check your build platform's status page, which people forget is a separate thing from their app's hosting.

This either ends the investigation immediately or eliminates four categories, and there is no cheaper information available anywhere in the hour. Subscribe to those pages now, today, so that next time it arrives as a notification rather than a search.

If a provider is having an incident, your job for the rest of the hour is communication rather than repair, and you can skip ahead to the section on what to tell users.

Minutes 12–30: the four usual causes, in order

If it is not the vendor and it is not local, it is nearly always one of these four, and the ordering is by how often I see them.

One: a deploy. Something went out and it broke. This is the most common cause and it is also the one with a clean, instant, reversible fix, which is why the next section is about rolling back rather than fixing.

Two: a limit you crossed. This one is nasty because there is no error in your code and nothing changed on your side — you simply went past a line on somebody's plan. Netlify pauses sites at the ceiling rather than billing overage. Supabase pauses free projects after a week of inactivity, so a quiet week can end with the database simply not there. Free-tier email has a hard daily cap that stops your transactional mail mid-afternoon with no visible failure in your app. Sentry's free plan stops accepting events after 5,000 in a month, so your monitoring goes quiet at exactly the wrong moment. Log into each provider and look for the word "limit" or "usage" on the dashboard.

Three: something expired. Credentials and registrations have dates on them and nothing warns you loudly. A domain that lapsed. A TLS certificate that failed to renew because a DNS record moved. An OAuth client secret with an expiry. An API key someone rotated last month, in one place and not the other. If the app is up but one specific integration is dead, this is where to look first.

Four: the vendor, quietly. Not a declared outage — a regression. This is the hardest one to confirm from outside, and the honest position is that you often cannot. It is worth knowing that this genuinely happens rather than being paranoia: a backend regression at Lovable between February and April 2026 ran for seventy-six days before it was publicly identified, and valid reports had been sitting in the queue for weeks because internal documentation described the behaviour as intended. If you have eliminated the first three and nothing on your side changed, "it is them" is a reasonable working hypothesis, and your options narrow to rolling back and waiting.

The most important decision: roll back, do not fix forward

If there is one thing to take from this page, it is this.

Fixing forward means diagnosing the problem and shipping a change that corrects it. It is the right approach when you have a staging environment, tests, and time. Under pressure, in production, with none of those, it goes badly in a specific and predictable way: you make a change, it does not work, you make another on top of it, and within forty minutes nobody can say what state the app is in. The outage is now longer than the original fault and harder to reason about.

Rolling back means returning to the last version that worked, before you understand why. It feels unsatisfying and it is almost always correct. Your customers get a working app in two minutes, the pressure drops to zero, and you diagnose the actual problem calmly, in a copy, with the business running.

Every host keeps previous deployments and lets you promote one back to production; every build platform keeps a version history. Find those two controls today, while nothing is wrong. Click into the screen, see what it looks like, confirm you know which button it is. Doing it for the first time during an incident, on a phone, while customers email you, is a genuinely different experience.

One caution: a rollback undoes code, not data. If the bad deploy also changed your database structure, going back to the old code against the new database can make things worse. If you know a migration went out with the change, that is the moment to stop and get help rather than to keep clicking.

If data is missing, this is a different incident

The runbook above assumes the app is broken. If the app works but data is wrong or gone, invert the first instruction: stop writes immediately. Take the app offline or put it in maintenance mode before anything else.

The reason is that a restore replaces the database with an earlier version, so every write that lands between the loss and the restore is a write you will lose, or have to reconcile by hand. Keeping the app up so customers are not inconvenienced is the intuitive move and it directly makes the recovery worse.

Then find out what your backups actually are, which for many people is the moment they discover the answer is "none" — free-tier Supabase has no backups at all, and paid tiers vary in how far back they go and whether point-in-time recovery was ever switched on. Uploaded files in storage are frequently not covered by a database backup, so you can restore every record and find that every document it points at is gone.

It is worth saying that automated agents deleting production data is not hypothetical. In July 2025 Replit's agent deleted a production database during an explicit code freeze, then fabricated data and incorrectly reported that a rollback was impossible; Replit's CEO called it unacceptable and the company shipped automatic development-and-production database separation in response. The lesson generalises well beyond Replit: an agent with write access to production is a category of risk that has to be designed against rather than trusted.

What to tell your users

A short holding message beats silence by an enormous margin, and it costs two minutes.

Say what is affected, that you know, and when you will next update. Do not diagnose publicly, do not promise a time you are guessing at, and do not blame a vendor before you are certain. "Signups are currently failing. We are on it and will update here within the hour" is complete and buys you an hour of goodwill.

If your app is entirely unreachable, you can usually point your domain at a static holding page from your DNS provider in a few minutes. It is worth having that page written and sitting in a folder before you need it, because writing copy while your app is down is not when your best sentences arrive.

Afterwards: the twenty minutes that make the next one shorter

Once it is up, before the relief wears off, write down four things: what broke, when, what actually fixed it, and what would have made you notice sooner. Half a page. Nobody else has to read it.

Then set up the things whose absence you just felt.

Error tracking on both server and browser, with one alert on your most important flow — the highest-value hour available in this entire category, because it turns the next incident from a customer email into a notification. An uptime monitor, where a free plan is genuinely production-adequate: fifty monitors at five-minute intervals costs nothing and would have told you first. A rollback you have practised once on purpose. A restore you have practised once on purpose, which is the only way "we have backups" becomes a fact rather than a hope. And a list of every credential and registration with an expiry date, in one document, because the alternative is finding them individually at the worst moment.

That is most of an afternoon and it changes the character of every subsequent incident.

The part you cannot fix with a runbook

There is a limit to how much of this is under your control, and it is worth naming rather than pretending otherwise.

When the failure is on someone else's platform, your options are to roll back, to communicate, and to wait. You cannot escalate meaningfully, you cannot see their logs, and support queues do not move faster because your revenue is stopped. That is not an argument against building on these platforms — the speed is real and worth a lot. It is an argument for making sure that your code lives in a repository you own and your database lives somewhere you can reach independently, so that "wait" is a choice rather than the only option. What each platform actually lets you take with you is set out in what you actually own when you export.

If you would rather not learn this during an outage

Most of what is above is preparation, and preparation is much cheaper than the incident it prevents.

I do a Production-Ready Audit that covers exactly this ground: whether your backups exist and have ever been restored, whether error tracking and alerting would actually reach you, what your rollback path is and whether it works, and which plan ceilings you are closest to crossing. From $499, back in five to seven days, with a written list in priority order.

If you are in an outage right now, send me what you have — the one-sentence description from minute five, and the timestamp of your last deploy. I will tell you which of the four causes it looks like. No charge, and no pitch attached; there is a decent chance the answer is "roll back and check your email quota", and that should not cost anybody anything.

The broader list of what is usually missing in an AI-built app, including the monitoring and backup gaps behind most incidents, is in the ten problems every AI-built app has in production, and the deployment-side work is described on the launch and deployment page.