> ## Documentation Index > Fetch the complete documentation index at: https://docs.uptimeio.com/llms.txt > Use this file to discover all available pages before exploring further. # Understanding Incidents > How UptimeIO confirms failures, opens and resolves incidents, and what you can do with them An incident records a period when a monitored service is failing or not meeting expectations. UptimeIO opens an incident only after a failure has been confirmed from several probe locations, so a single network glitch does not page you. ## How an incident is opened A scheduled check fails from one probe location. **No incident yet**: it could be a transient problem. About one second after each failure, the check is repeated from a different probe location, up to three attempts in total. An incident opens only when **several probe locations agree** that the target is failing. See [Probe locations](/monitors/probe-locations) for where checks run. If a confirmation check succeeds, the failure is treated as transient and no incident is opened. Every verified [notification destination](/notifications/overview) assigned to the monitor that has the "Monitor goes down" event enabled is alerted. This applies whichever locations you select on a monitor. Selected locations decide where regular checks run; confirmation checks prefer them but use the other locations when needed, so the rule holds even with a single selected location. ## How an incident is resolved Recovery mirrors detection: **several locations must see the target succeed** before the incident resolves. This prevents flapping, where a service bounces between failing and passing and creates alert fatigue. When the incident resolves, destinations with the "Monitor recovers" event enabled are notified. You can also resolve an incident manually with **Resolve** on its page. ## Incident types Each incident shows a type that describes the cause: | Type | Raised when | | - | - | | Timeout | The target did not respond in time (also used for missed heartbeats). | | Connection error | The connection could not be established. | | Status code | The response status was not one of the expected codes. | | Keyword missing | A keyword monitor did not find (or unexpectedly found) its keywords. | | DNS error | DNS resolution failed. | | DNS validation error | DNS records did not match the expected values. | | SSL error | The TLS certificate is expired or invalid. | | Slow response | Response time exceeded your threshold. | ### Slow response Turn on **Slow Response Alert** on an HTTP or keyword monitor and enter a threshold in milliseconds to be told when responses are too slow. * A slow-response incident is **separate** from a downtime incident: a monitor can be up and still have an open slow-response incident. * It resolves when response time stays **below 80% of the threshold for 3 consecutive checks**. With a 2,000 ms threshold, that is under 1,600 ms for three checks in a row. ### SSL certificate problems Certificate **expiry warnings** (30, 15, 7 and 1 days before expiry, whichever you selected) are sent to your notification destinations and do **not** create an incident. An **expired or invalid** certificate does open an SSL error incident, which resolves automatically once a valid certificate is seen. See [Setting Up Alerts](/essentials/setting-up-alerts#certificate-and-domain-expiry-warnings). ## Statuses and severity | Status | Meaning | | - | - | | Open | The incident is active. | | Acknowledged | A team member has seen it and is working on it. | | Resolved | The service has recovered. | | Closed | Final state. No further changes. | An open incident can be acknowledged or resolved, an acknowledged one resolved or closed, and a resolved one closed. Severity is Critical, Major, Minor or Warning. ## Reading an incident Open **Incidents** in the sidebar and select an incident. The page shows: | Section | What it tells you | | - | - | | Header and metadata | Title, type, severity, status, start time, duration and affected locations. | | Timeline | What happened and when, including confirmation attempts and status changes. | | Affected monitors | Which monitors the incident covers. | | Notification delivery | For each notification sent: channel, and whether it was **Sent**, **Failed** or **Pending**. | | Comments | Team discussion on the incident. | The incident list can be filtered by status, severity, and search text. ## Reduce false alarms Set the monitor's **Timeout** (maximum 60 seconds, shorter than the check interval). Use 10 to 15 seconds for fast APIs and up to 60 seconds for slow services. Timeouts that are too short cause failures that are not real. The default accepts only 200. If your endpoint returns 201, 204 or a redirect status you rely on, add those codes under **HTTP Configuration**. If a firewall or rate limiter blocks probes, allow this user agent: ```text theme={null} UptimeIO-Monitor/1.0 (+https://uptimeio.com/monitoring-bot) ``` ## Next steps Choose who is notified Uptime and response time Monitor settings Keep customers informed This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.