Blog · 3 October 2026

Your site went down at 3 AM. Now what?

What Kernel6 checks, what the alert email means, and a calm checklist for getting a crashed app back online.

Sooner or later an app crashes at an inconvenient hour. The goal is not to never crash — it is to find out quickly, from someone other than an annoyed customer, and to know where to look. Here is how that works on Kernel6, including the limits of what it can see.

What we actually check

Every five minutes, the platform asks the process manager on each server what state every app is in, and compares that with what the dashboard believes. If an app has errored, or its process has disappeared, the project is marked as crashed and you get an email titled [Kernel6] your-project is down, with a link straight to its logs.

While it stays down you get at most one reminder a day — not one every five minutes. When it comes back, you get an email saying it has recovered. Stopping an app yourself never triggers an alert, because that was on purpose.

An honest limit: this check watches whether your app’s process is running. An app that is running but returning error pages to visitors still counts as up. If your site depends on a database or an external API, consider an endpoint that checks those too, and an external uptime monitor that loads a real page.

Restarts that happen without you

Each app has a memory limit of half its server. If the app exceeds it — a slow memory leak, typically — the process manager restarts it automatically. Most of the time you will never notice. A crash that persists after those restarts usually means the app is failing as it starts, which is exactly what the logs will show.

A calm checklist

  1. Open the project and look at Runtime logs. They show the last lines your app printed, pulled live from the server. A stack trace near the bottom is usually the answer.
  2. Ask what changed. Look at Deploy history: did a deploy finish shortly before the crash? Open its build output and compare it with the previous successful one.
  3. Check your environment variables. A missing or mistyped DATABASE_URL is the most common reason a freshly deployed app starts and then dies. Remember that changes need a redeploy to take effect.
  4. Check the things your app depends on. If the database or a third-party API is down, your app may be crashing on startup because it cannot connect.
  5. Try a restart from the project page. If the cause was temporary, that is the fastest way back. If it crashes again straight away, it is a code or configuration problem — go back to the logs.
  6. If you need to roll back, push a commit that reverts the change and deploy again. Deploys always build the latest commit on your branch.

Make the next crash easier

  • Log something useful when your app starts — the port, the environment, whether the database connected. It makes the first line of the runtime logs informative.
  • Fail loudly and early on missing configuration, with a clear message naming the missing variable.
  • Run your build locally before deploying. A failed build stops the previous version too, so a broken build means downtime.
  • Keep the alert email address on your account one you actually read.

And if you have been through the list and are still stuck, get in touch through the contact page with your project name. We can see the same logs you can.

More from the blog