Documentation

Documentation

Incidents, responders and postmortems

How incidents open and close automatically, what the lifecycle states mean, and how to run the workflow through to a postmortem.

Last updated August 10, 2026

When does an incident open?

Automatically, when consecutive failed checks cross the monitor’s failure threshold — 2 by default. One incident stays open per monitor per failure type, so a site that is down for an hour produces one incident, not twelve.

It closes automatically once successes cross the recovery threshold, which is 1 by default — so an incident resolves on the first good check unless you raise it — and a recovery notice goes to the same channels that got the alert. You do not have to close incidents by hand for the common case.

What do the lifecycle states mean?

Open means the failure is current and unacknowledged. Acknowledged means a human has taken it — the alert stops repeating but the incident stays open, which is the state you want while you are actually fixing something. Resolved means the checks recovered or you closed it manually. Reopened means it resolved and then failed again inside the same window, which is worth noticing because it usually means a fix did not hold.

Acknowledging is the step teams skip, and skipping it is how two people end up debugging the same outage in separate windows.

What is a responder, and who can assign one?

A responder is the person who owns the incident. Assigning one is a Team-plan field. It does not change alert routing — PageLantern has no on-call rotation of its own — it records ownership so the incident timeline says who was working on it.

If you need alerts routed to whoever is actually on call, forward to PagerDuty and let that system decide. That is the honest division of labour: we detect and record, they page.

What goes in a postmortem?

Postmortem fields are available on the Team plan and attach to the resolved incident, so the record and the analysis live together rather than in a document nobody can find in six months.

Write what happened, what the impact was in customer terms, what the trigger was, and what you are changing. Resist writing who made the mistake: a postmortem that assigns blame is a postmortem that gets written less honestly next time, and the reason PageLantern keeps the timeline and the notification history is so the facts do not have to be reconstructed from memory.

Why did an incident open when my site was fine?

Most often the target refused our probe rather than failing. Bot protection, WAF rules and per-IP rate limits treat monitoring traffic as unwanted, and a 403 from a bot-protection challenge looks like a failure unless it is recognised as a refusal.

PageLantern distinguishes a proven refusal from a genuine failure and marks the monitor as probe-blocked rather than down — the UI shows "Not measured" rather than a false red. See the operational states guide for what that state means and how to allowlist our probe so measurement resumes.