Monitoring & logs
What Kernel6 watches, when it emails you, and where to look when something goes wrong.
What is checked
Every five minutes, Kernel6 asks the process manager on your server for the state of each app and compares it with the status in your dashboard. The dashboard status always reflects what the server reports right now, not what the last deploy said.
| Status | Meaning |
|---|---|
| Live | The app's process is running. |
| Deploying | A deployment is in progress. |
| Stopped | You stopped it from the project page. |
| Crashed | The process errored, or is no longer running. |
| Failed | The last deployment did not complete. Its build log says why. |
This is a process check. An app whose process is running but that returns error pages — for example because its database is unreachable — still shows as live. For checks on real pages, pair Kernel6 with an external uptime monitor that loads your site.
Alert emails
- Down: when an app changes to crashed, the account owner gets an email titled
[Kernel6] your-project is down, with the time it was detected and a link to its logs. - Reminder: if it is still down, at most one reminder a day — not one every five minutes.
- Recovered: when it is running again, an email titled
[Kernel6] your-project is back up.
Stopping an app yourself never triggers an alert. A deploy that fails after the old version was stopped leaves nothing running, so it is reported as down at the next check. Alerts go to the email address on your account, so keep it one you read.
Automatic restarts
Apps run under the pm2 process manager, which restarts an app that exits unexpectedly. Each app also has a memory limit — half of its server, never less than 512 MB — and is restarted if it exceeds it. A crash that persists after restarts usually means the app is failing as it starts; the runtime logs will show why.
Runtime logs
Runtime logs on the project page shows the last 200 lines your app has printed — console.log output and errors — fetched live from the server when you open it. Choose Refresh to fetch the latest. Logging a line when your app starts (port, environment, whether the database connected) makes this far more useful.
Build logs and deploy history
Each deployment keeps its full build output. Deploy history lists recent deployments with their start time, status, duration and address; select one to read its log. When a deploy fails, comparing its log with the last successful one is usually the fastest way to see what changed.
When your site is down
- Open Runtime logs and look for an error near the end.
- Check Deploy history: did a deploy finish just before the crash?
- Check environment variables — a missing value is a common cause — and remember changes need a redeploy.
- Check anything your app depends on, such as its database or a third-party API.
- Try a restart from the project page. If it crashes again straight away, fix and redeploy.
A longer version of this checklist is in Your site went down at 3 AM. Now what? If you are still stuck, contact us with your project name.