---
title: "Incidents"
description: "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`, `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:

- **`downtime`** means the certificate is rejected right now: it has expired, it was revoked, or a real browser refused the page (for example `net::ERR_CERT_COMMON_NAME_INVALID` for 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](/status-pages), 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](/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.