Incidents

Incidents are created automatically when monitoring detects a problem with a website or service. They are the foundation for alerting, reporting, and the public Status Pages.

Where to find incidents

• Incidents overview: /incidents
• Per website / monitor: most detail pages include an incident history tab

Incident lifecycle

Incidents have two primary states:

• open — the issue is still ongoing
• resolved — the service recovered and the incident was closed (automatically, once checks pass again)

What an incident contains

Depending on the check type, an incident can include:

• Type / severity — for example downtime, http_status, performance, ssl_warning, ssl_expiry
• Start / resolved time
• HTTP status code (if applicable)
• Response time (ms) (if applicable)
• Error message — network errors, timeouts, parsing failures, etc.
• Last notified timestamp — used for notification reminders

Incident details (timeline & evidence)

From the incidents list, open the details modal to see:

• A timeline of confirmation → outage → recovery
• The evidence check (the monitoring check that served as proof)
• An optional traceroute excerpt
• An optional screenshot (when available)

This answers "what exactly happened?" without digging through raw logs.

How incidents map to status page state

If the customer has a public status page, open incidents change the displayed service state:

The overall page banner reflects the most severe state across all services. See Status Pages → How the public state is derived.

Inconclusive checks (browser verification timeouts)

Some sites use bot protection / browser verification that can time out. In these cases Uptimeify may mark a check as inconclusive rather than treating it as full downtime — so you don't get misleading "everything is down" alerts and incidents from a protection challenge rather than a real outage.