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 ongoingresolved: 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,ssl_handshake - 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
ssl_handshake: the server aborted the TLS handshake (for example with an internal_error alert) and never established a secure connection, so the site is unreachable over HTTPS.
How certificate problems are classified
A certificate problem is only a warning while visitors can still reach the site. Once a browser rejects the certificate, the site is unreachable, and the incident is treated like any other outage:
downtimemeans the certificate is rejected right now: it has expired, it was revoked, or a real browser refused the page (for examplenet::ERR_CERT_COMMON_NAME_INVALIDfor a hostname the certificate is not valid for). Visitors see a full-page interstitial instead of your site, so this is an outage and alerts at critical severity. The error message on the incident still names the certificate cause.ssl_expiry, the certificate is still valid but has reached the critical threshold before expiry. Nobody is blocked yet; this is a warning.ssl_warning, a certificate problem we could not prove is blocking visitors. Also a warning.
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:
| Incident situation | Status page state |
|---|---|
| No open incidents | operational |
| Only SSL warning incidents open | warning |
| Any other open incident (downtime, http_status, performance, …) | degraded |
| Active maintenance window, no open incidents | maintenance |
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.
Custom Domains
Connect a hostname like status.deinkunde.com to a status page so it runs entirely under your own brand. A hostname can be bound to exactly one status page, and the certificate is issued automatically once the domain is verified and active.
Maintenance
Maintenance windows let you plan work (deployments, updates, migrations) without triggering noisy alerts. During an active window the affected target is treated as in maintenance. Alerts are suppressed and, if the customer has a status page, the service is shown as Maintenance instead of Degraded.