What happens when your vibe-coded app goes down at 3am

It’s 3:04am. Somewhere, an app that worked fine yesterday is now returning a blank white page to every visitor. The founder is asleep. The users are in a different time zone and very much awake. Nobody has noticed yet except a monitoring check that just went red.

This is a walkthrough of what happens next, or what should happen. It’s a composite of the patterns we see across AI-built apps, not one specific incident. Names and numbers are illustrative. The anatomy is real and it repeats.

3:04am, the alert

The first thing that should happen is that a machine notices before a human does.

A monitoring tool pings the app every minute or so. When the check fails a few times in a row, it fires an alert. Not an email nobody reads at 3am, an actual page to whoever is on call. On our setup that’s Uptime Kuma watching the app and firing when it goes dark.

Here’s the difference that one piece makes. On a well-run app, the on-call person learns about the outage from a monitor at 3:04am and starts working. On a typical unmonitored vibe-coded app, the founder learns about it at 9am from an angry customer email, after six hours of downtime and a dozen lost users. Same outage. Wildly different morning. The alert is the cheapest, highest-impact part of the whole story.

3:07am, first look

Now someone’s awake and looking. The first job isn’t to fix anything. It’s to figure out what’s actually broken, fast, without making it worse.

The instinct people have is to start restarting things and changing settings. That’s how a small outage becomes a data-loss incident. The disciplined move is to look before you touch.

A quick triage runs roughly like this:

• Is the app process alive? Check whether the container or service is running at all, or crashed and stayed down.
• Is the database reachable? A huge share of outages are really the app being unable to talk to Postgres, not the app itself.
• What do the logs say right before it died? The last few lines before the failure usually name the culprit.
• What changed recently? A deploy an hour ago, a traffic spike, a full disk. Something moved.

This is also where good logging earns its keep. If the app writes readable logs you can search, this step takes two minutes. If it writes nothing, you’re guessing in the dark at 3am, which is exactly when you don’t want to guess. We wrote more on that in logging for AI-generated backends.

3:12am, the diagnosis

Say the logs show the classic line: remaining connection slots are reserved for non-replication superuser connections. The database stopped accepting connections. The app is up, but it can’t reach its data, so every page fails.

That points at connection exhaustion. A traffic bump, an app that opens a database connection per request and doesn’t return it, no pooler in front to absorb the flood. The connections climbed until they hit Postgres’s ceiling, and then nothing new could get in. It looks like an attack and it’s almost never an attack. We took that specific failure apart in a postmortem on connection pool exhaustion.

The point of the anatomy isn’t this one cause. It’s the shape: a symptom that looks scary, a log line that names the real problem, and a diagnosis that’s usually something boring and preventable rather than something dramatic.

3:18am, the fix

At 3am you have two different jobs, and mixing them up makes things worse.

Job one: get it back up now. For connection exhaustion, that might mean restarting the app to drop the stuck connections and putting a pooler in the path so the flood gets absorbed. The app comes back. Users can load pages again. The bleeding stops.

Job two: fix the actual cause. That’s the connection leak in the app and the missing pooler as a permanent setup, not a 3am patch. This job does not happen at 3am. You do the safe, reversible thing to restore service, then you fix the root cause properly in daylight when you’re awake and can test it.

The single most important rule at 3am: don’t do anything irreversible to the data. No dropping tables, no destructive migrations, no “let me just delete this to see if it helps.” A restore-from-backup should be a deliberate, tested operation, not a panicked 3am gamble. If the fix might touch data, that’s where a tested backup and a calm process matter more than speed.

By 3:24am the app is back. Twenty minutes of downtime that a monitored app caught immediately, instead of six hours an unmonitored one wouldn’t have noticed until breakfast.

The next morning, the postmortem

The outage isn’t over when the app comes back. It’s over when it can’t happen the same way again.

A good postmortem is short and blameless. It answers four questions:

1. What happened? Plain timeline. Alert at 3:04, diagnosed connection exhaustion at 3:12, restored at 3:24.
2. Why? Root cause, not just the symptom. The app leaked connections and had no pooler, so ordinary traffic hit the ceiling.
3. What did we change? The permanent fix. Pooler in place, leak fixed, an alert on connection count so we see the creep before the wall.
4. How do we stop the whole class of this? The systemic lesson, not just the one bug.

Notice there’s no hunt for someone to blame. The app was built by an AI tool that produced code that worked in the demo and didn’t handle 300 users at once. That’s not a character flaw, it’s the normal gap between “works” and “survives.” The postmortem’s job is to close that gap, calmly.

The real lesson

Reread the timeline. The dramatic-sounding 3am outage was, underneath, a boring and preventable problem: no monitoring, no pooler, no tested backup, no logs. The apps that come through their first real trouble aren’t the ones with the cleverest code. They’re the ones where someone set up the unglamorous safety net before the bad Tuesday, not during it.

If your app has real users and you’ve never checked whether it has monitoring, a connection pooler, or a backup you’ve actually restored, that’s the gap that turns a 20-minute scare into a 6-hour disaster. The free audit is built to find exactly those holes before 3am does. No sales pitch attached to the findings, just the honest picture of what would hurt if your app broke tonight.

FAQ

Why do AI-built apps break at 3am specifically?

They don’t prefer 3am, but that’s when there’s no one watching. AI tools produce code that works for one user in a demo and often skips the operational safety net: monitoring, pooling, tested backups. So the app runs fine until a spike or an edge case hits, frequently in the small hours when traffic from another time zone arrives and no one’s awake.

Wouldn’t I just get an alert on my phone?

Only if you set one up. Most vibe-coded apps have no monitoring at all, so the “alert” is an angry customer email hours later. A one-minute uptime check that pages you is one of the cheapest things you can add and it changes a six-hour outage into a twenty-minute one.

What should I never do during a 3am outage?

Anything irreversible to your data. No dropping tables, no destructive migrations, no panicked deletes. Restore service with safe, reversible actions, then fix the real cause in daylight when you’re awake and can test it. A backup restore should be a deliberate, tested process, not a 3am gamble.

How do I make my app resilient enough to survive one?

The unglamorous four: monitoring that pages you, a connection pooler in front of Postgres, backups you’ve actually restored at least once, and readable logs you can search. None of it is fancy. All of it is the difference between a scare and a disaster.