Platform Alerts
What this screen is for
Platform Alerts exists for one reason: a condition the platform renders as a problem must be able to reach a human who is not looking at the screen. The System Health panel already shows every condition evaluated here. What it cannot do is tell you about one at three in the morning.
It is one of the three cards under Observability & Audit that hold no configuration value. It administers two kinds of record: conditions — a closed catalogue of twenty, which you tune but cannot add to — and destinations, where a notification is delivered.
The catalogue is closed on purpose: the platform knows its own failure modes and a deployment cannot invent one. With no destination configured the screen still renders the full catalogue with its defaults, and states plainly that nothing will be delivered. That is the honest state — the platform is configured and undelivered, which is not the same as unconfigured.
The screen re-computes nothing. No threshold is compared here and no condition is decided to be firing; every value shown was decided by the platform. A second opinion computed in the browser would be visibly wrong exactly when it matters.
What must exist first
This is a platform screen, reached in the platform context and served only to the platform tenant. There is no per-tenant plane: alerting is the platform's own, by construction. Three separate permissions apply, and holding platform-configuration read carries none of them:
- The permission to read alerts, which lists the conditions, the destinations and the current state.
- The permission to write alerts, for tuning a condition or creating, editing and deleting a destination.
- The permission to test a destination, gated separately from write — because a test delivers a real message to a real recipient, who cannot be un-notified afterwards.
- A working outbound delivery path. Without one the platform answers a test as unavailable rather than recording a verdict for a delivery that never happened.
Decisions you make here
Tuning a condition
Each condition shows what it means as the platform states it: a title, what it measures, why it matters and the first thing to do, in your language. The screen keeps no wording of its own, so the catalogue you read is the one the messages are written from.
You can change up to four settings. Enabled switches a condition off entirely. Threshold is a percentage, and exists only on the conditions that measure one — a condition that asks whether a service is up has none, and supplying one is refused. Dwell is how long the condition must hold before it fires, which suppresses flapping. Cooldown is the minimum interval between repeat notifications while it is still firing; a scheduled condition has none, because its weekly slot is its whole cadence. Durations are shown in days, hours and minutes.
While a condition holds but its dwell has not yet elapsed, System Health shows it as pending and nobody is notified; it fires, and notifies, once the dwell completes.
Three conditions watch the backups: backups that could not be restored without the host, no recent successful backup, and a failed last backup run. They take no threshold; how many days a backup may age is a deployment setting, 7 days by default. They decide nothing of their own: each one fires exactly when the Recovery readiness card on System Health lists its reason.
Some conditions are marked Security detection: they fire when the platform is under attack or has lost a security control. Only a platform super administrator can change one, its dwell is at most one hour, and its warnings are never held for quiet hours. The same holds for removing or narrowing the last destination that receives critical or warning alerts, because that silences those conditions too.
Two refusals are worth knowing before you meet them. A condition that is evaluated against a threshold may not be left without one — omitting it would silence the condition permanently rather than relax it. And on the repeated-restarts condition the dwell must be shorter than its observation window; at or above it the condition could never fire.
The three tiers are named for what the platform does with them. Critical is delivered immediately, at any hour. Warning is delivered immediately, except to a destination whose quiet hours are in effect: there it waits for the end of the window. Scheduled goes out once a week, in the digest, at the slot shown on the tier's heading. A scheduled condition reports a work list rather than an incident, so it has no resolved counterpart.
Previewing a message
Preview shows exactly what a condition's message would say — the subject, the email text, the SMS text and the webhook body — rendered by the platform from a realistic sample, with this environment's name and the real link. Nothing is sent, and reading alerts is enough to use it.
The weekly digest slot
The day, time and time zone of the weekly digest are shown on the scheduled tier. A super administrator edits them here; everyone else reads them. A change applies to the next slot after it, never at the moment you save it, and a slot that has already passed this week is not sent late. The time zone is a region such as Europe/Madrid, or UTC, which is the default; a fixed offset is refused because it does not follow daylight saving time.
Destinations, and the one that is different
An alert destination has a channel — email, SMS, WhatsApp or webhook — and the set of severities it accepts. Routing lives on the destination: with one platform administrator there is no routing tree to express, only a per-destination filter. Narrowing a destination's severities is the supported way to stop hearing about something, rather than disabling the condition.
An alert destination may also keep quiet hours: a local window, such as 22:00 to 07:00 in your zone, during which warnings for it are held and delivered when the window ends. Critical alerts and the weekly digest are never held. The window ends exactly at its end time, and it may span midnight. Quiet hours hold warnings only, so they are refused on a destination that does not accept warnings, as is a window whose start and end are the same. The zone must be a region such as Europe/Madrid, or UTC; a fixed offset is refused because it does not follow daylight saving time.
Heartbeat is the second purpose, and it is not an alert. It is a small signed ping to a webhook, sent at an interval you choose between one minute and one hour. The interval is required: the form starts at five minutes, but the platform keeps no default of its own.
Point it at an external check such as healthchecks.io, Better Stack or Cronitor, set that check's period to the same interval and its grace to at least one interval plus one evaluation interval, and let the check page you when the pings stop. A heartbeat is webhook-only and has no severities or quiet hours; the form fixes the channel for you.
Exactly one enabled heartbeat destination may exist — the platform refuses a second. Its endpoint is always held to the strict rule regardless of deployment type, because a receiver inside your own network sits in the very failure domain it exists to escape.
Sending a test, and reading the verdict
Send test delivers a real message through the real path: the same sample the preview shows, marked as a test. A heartbeat destination's test sends a ping. It is rate-limited to one test per destination per minute, and the limit is per destination rather than per operator because the flood lands on the recipient either way. A test that could not send anything does not consume that window.
The result is recorded on the row and read back on every load: a verdict of delivered, refused, unreachable or unknown, the time, and a short plain-language reason. The reason is there because one word cannot answer your next question, which is always what to fix — "refused" on an email destination may mean the deployment has no email provider configured at all, and that sentence is worth more than the verdict.
The one value that is not here
How often every condition is measured is not on this screen. It lives as a configuration value under Tracing & Metrics in the same group, and it also sets how often the System Health document is refreshed — they are the same measurement. Shortening it makes alerts and the panel fresher and multiplies the probing across every service. The heartbeat and the digest keep their own schedules; this interval only bounds how late either can be.
How it relates to other screens
This surface sits inside the Observability & Audit group, beside the two other subsystems that administer records rather than values:
What these conditions measure is drawn in full on the health panel, and the delivery channels a destination uses are configured as an integration of their own.