Skip to content
aknWiki

Incidents

The Incident Reports section sits at the foot of the page, below the service cards. It holds two lists: Active Incidents and Past Incidents.

Incidents arise in two ways. Most are raised automatically from recorded check failures. An operator can also declare one, in which case the wording is the operator’s own.

What an incident record contains

Section titled “What an incident record contains”
Field Shown for Contents
Date All incidents The day the first failed check was recorded, as 18 Jun 2026
Service All incidents The name the affected service is monitored under, on a grey badge
Status Active incidents investigating on a red badge, or monitoring on a yellow badge
Title All incidents The service name and the severity wording
Description All incidents The affected address, the duration measured, and the start time in GMT
ETA Active incidents An expected resolution time
Resolution Past incidents A timestamp in GMT followed by Service restored

Automatic titles and wording

Section titled “Automatic titles and wording”

Automatic incidents take their title from the measured duration.

Measured duration Title Description pattern
Under one hour <service> Service Disruption Reports downtime starting at a given time
One hour to 24 hours <service> Extended Outage Reports an approximate number of hours
Over 24 hours <service> Multi-Day Outage Reports a number of days

How an incident is raised

Section titled “How an incident is raised”
Rule Detail
Threshold Two consecutive failed checks for the same service
Effect of the threshold A single failed check never produces an incident
Active The most recent failure is within the past two hours
Past The most recent failure is more than two hours old
Excluded The external reference address raises no incidents

Because checks are commonly one to two hours apart, an interruption must persist for hours before it is recorded as an incident. Short interruptions appear on the history bar without producing an incident entry.

How history is presented

Section titled “How history is presented”
Property Detail
Order Newest first, in both lists
Grouping By incident, not by service. A service with repeated outages appears repeatedly
Retention An incident is listed for as long as the check history covering it is retained
Empty active list Displays All systems operational
Empty past list Displays No past incidents
Automatic scroll When an active incident exists, the page scrolls to the incident section shortly after loading
Pagination None. All retained incidents are listed at once

An incident moves from Active Incidents to Past Incidents on its own once the service answers again. No notice is issued.

Interpreting a past incident

Section titled “Interpreting a past incident”
Element How to read it
Start time The time of the first failed check. The interruption began at some point after the previous successful check
Duration Measured from the first failed check to the last. It understates the true interruption by up to the gap between checks
Restoration time The time of the last failed check. The service answered again at some point before the next recorded check
Address shown as Unknown URL The service is no longer monitored. Its past incidents remain listed
Approximate hours or days Rounded. Treat the figure as indicative

Durations state when the address stopped answering, not what caused it. The page carries no cause, no affected-feature breakdown, and no follow-up notes.

ETA on active incidents

Section titled “ETA on active incidents”

An automatic incident carries an expected resolution time set 24 hours after the incident was raised. The figure is a fixed placeholder rather than an estimate of the work involved.

Treat the ETA as a review point, not a commitment.

Section titled “Related”