What the Platform Tells You — and What It Never Will

There's a Notifications section in the panel, and it's worth knowing exactly what fills it — because the boundary is sharper than people expect. The platform notifies you about platform events: your balance, resource limits, scheduled restarts, and messages from support. It never notifies you about your application's behaviour. No message arrives when your bot stops replying, when your handler starts throwing, or when your process is crash-looping — because nothing probes your app to find out. Notifications are emailed as well as shown in the panel.

What you'll actually be told#

The events that generate a notification are the ones where the platform did something to your apps, or where money moved:

• Resource limits exceeded. The most consequential one — if total volume size passes your account's disk limit, your apps are stopped, and you're told. That's account-wide, so it can affect apps unrelated to the one that filled up.
• Balance events. A payment crediting your account produces a note; running out produces the corresponding one, along with apps being stopped.
• Scheduled restarts. When maintenance means your app will be restarted, you get advance notice with the time, and usually a confirmation afterwards.
• Messages from administrators. Support can send you a notification directly — which is why an unexpected one is worth reading rather than dismissing.

Notifications carry a severity — informational, attention, or alert — so the list isn't undifferentiated. Anything about your apps being stopped is at the serious end.

They go to your email too#

This is the part worth acting on today. Notifications aren't only a panel feature: each one is also sent as an email to the address on your account.

Two consequences:

• Use an address you actually read. If you signed up with an address you check quarterly, you've effectively opted out of the only channel that tells you your apps were stopped.
• Check your spam folder once. Transactional mail from a service you've used twice is exactly what filters treat harshly, and the first time you find out is a bad time.

It also means you don't have to poll the panel. For a side project you check occasionally, email is the notification system — the panel is just where they're also listed.

What you will never be told#

Here's the boundary, stated plainly. No notification will ever arrive because:

• Your app crashed, or is restarting in a loop.
• Your bot disconnected from the gateway and went quiet.
• Your HTTP service started returning errors, or stopped answering entirely.
• A background job inside your app is failing every time it runs.
• Your model API calls are being rejected, or costing more than you expected.

That's not an omission to work around — it follows from the design. There are no health checks, and the platform's view of your app is whether the container is running. A container that's up and useless looks identical to one that's up and working.

So build the other half#

The good news is that the missing half is small, and it's the same work whatever platform you're on:

• Have your app tell you. An error handler that pushes a message to a self-hosted ntfy instance or a Discord webhook covers most of what you'd want, for a few lines of code.
• Add a liveness check the app can fail. A watchdog that exits when a heartbeat goes stale converts a silent hang into a restart you can see.
• Watch from outside. For a port-less worker, a push-style monitor — the app checks in, and silence is the alarm — is the only external check that works. Uptime Kuma does this and runs comfortably as a small app.
• Alert on spend, not just errors. A daily token-usage threshold catches runaway costs that no error will ever report, because nothing is failing.

Set up the first one today and the rest when you need them. One "something broke" push beats a monitoring stack you'll configure next month.

Which alerts deserve to wake you#

Worth deciding in advance, because everything feels urgent at 2am:

The two at the top of that list are the ones the platform sends and the ones you can't ignore, because they're states that persist until you do something.

FAQ#

Does the platform email me when my app goes down?#

No. It emails you about platform events — resource limits, balance, scheduled restarts, admin messages. Your app's health isn't monitored.

Where do notifications appear?#

In the Notifications section of the panel, and as email to the address on your account.

Why didn't I get told my bot crashed?#

Nothing probes your app. The container was running the whole time, which is all the platform observes.

What's the most important notification to act on?#

Apps stopped because of a resource limit. It's account-wide and stays that way until you free space or top up.

How do I get alerted about my own app?#

Have the app report its own failures to a push service or chat webhook, and add an external check that alerts on silence.

Should I change my account email?#

Make sure it's one you read. It's the channel that carries the notifications you can't afford to miss.

Wrapping up#

Knowing where a platform's responsibility ends is more useful than assuming it's larger than it is. Here it's clean: the platform tells you when it affects your apps — stopped for resources, restarted for maintenance, paid or unpaid — and stays quiet about everything happening inside them. Make sure those messages reach an inbox you read, then spend twenty minutes giving your app a voice of its own. After that, silence actually means everything is fine.