Incidents
Understand and investigate incidents created by monitoring checks.
Incidents
Incidents are automatically created when monitoring detects a problem with a website or service.
They are the foundation for alerting, reporting, and (optionally) 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 ongoingresolved: the service recovered and the incident was closed
What information an incident contains
Depending on the check type, incidents 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 you can open the details modal, which shows:
- A timeline of confirmation / outage / recovery
- An evidence check (the monitoring check that served as proof)
- Optional traceroute excerpt
- Optional screenshot (when available)
This is meant to answer: “What exactly happened?” without having to dig through raw logs.
How incidents affect status pages
If a customer has a public status page configured:
- Any service with one or more open incidents is shown as Degraded.
- Incidents can also appear in Recent History (depending on the status page settings).
Troubleshooting
Inconclusive checks (browser verification timeouts)
Some websites use bot protection / browser verification that can time out.
In these cases, Uptimeify may mark the incident as inconclusive/degraded instead of treating it as full downtime, so you don’t get misleading “everything is down” reporting.