Incidents

An incident is Moonitor’s record of a period of downtime for a single monitor. It captures when the problem started and the cause — the failure reason reported by the check that failed. Once the monitor recovers, the incident also records when it ended and how long it lasted.

Incidents give you a clean timeline of every outage, so you’re never guessing about what happened or for how long. Each one is tied to the monitor it belongs to.

Every incident moves through the same stages:

1. 1

   A check fails — and we check again, from somewhere else

   A single failed check is a claim, not a fact. Before opening an incident, Moonitor re-runs the check from a different country. If that checker can still reach you, the failure was ours, not yours: no incident opens, nobody is alerted, and the check doesn’t count against your uptime. If we can’t reach the second checker at all, we trust the first and carry on — we’d rather send an alert we’re unsure of than sit on an outage.

2. 2

   The failure is confirmed — the incident opens

   Once a second country sees the same failure, Moonitor opens an incident, records the start time and the cause, and moves the monitor into the Down state. The cause names the country that confirmed it, so the alert arrives with evidence behind it.

3. 3

   The monitor stays down — the incident stays open

   For as long as the monitor keeps failing, the incident remains open and continues to track the ongoing outage. We don’t re-verify every check while it’s down — we already know.

4. 4

   The monitor recovers — the incident resolves

   The next successful check — or, for heartbeat monitors, the next ping — resolves the incident. Recoveries are corroborated the same way a failure is, so a monitor can’t flap back to green on one hopeful result. Moonitor records the end time and calculates the total duration.

Incidents are what drive your alerts. When an incident opens, Moonitor sends a “down” alert to the monitor’s contacts on the first failed check. When the incident resolves, a “recovery” (up) alert goes out — but only to the contacts that were actually notified about the down, so you always get the matching all-clear and never a recovery for an alert you never received.

You can acknowledge an open incident to signal to your team that someone is looking into it — useful for avoiding duplicate effort when several people get the same alert.

Incidents show up across the dashboard so you can spot and review them quickly:

Resolved incidents stay in your history, so you can look back over past outages and their durations whenever you need to review reliability or report on it.

Incidents can also be reflected publicly on your status pages so your users know what’s happening without having to ask.

The incidents above are detected automatically and belong to a single monitor. A published incident is the other half: the thing you write for your customers. It belongs to a status page rather than a monitor, it has a title and a running thread of updates, and you can open one for something no probe can see — a partial degradation, a third-party outage, a data problem.

1. 1

   Publish it

   On the status page, choose Publish an incident. Give it a title, a severity, and a first update saying what you know. Pick the services it affects.
2. 2

   Post updates

   Add to the thread as things change, moving it through Investigating → Identified → Monitoring. Subscribers are emailed on every update, not only at the end.
3. 3

   Resolve it

   Post a final update and set it to Resolved. The page returns to normal and the incident moves into the history feed, keeping its permalink.

You can also fold detected outages into a published incident. Six monitors on one dead server then read as one story on your status page instead of six unrelated entries, and the underlying incident records are left untouched, so your uptime figures do not move.

Incident bodies are plain text. Line breaks are preserved; anything that looks like markup is shown as the characters you typed. That is deliberate — it is what makes it safe to publish these on a page your customers trust.

Published incidents are also available over the public API, so you can open one from CI or an alerting webhook.

• Alerts & contacts — where down and recovery notifications go.
• Managing monitors — the monitors that incidents belong to.
• Status pages — show incidents to your users publicly.