Uptime Monitoring: Incidents
Overview
Use this page to review and manually resolve uptime monitoring incidents. An incident is the record of a period when a configured check was failing. It opens only on a failed run, and only once the check's Failure Detection Mode says so: on the first failure (Immediate, the default), after a number of failures in a row (Retry Count, 3 by default), or after a number of failures within a time window (Time Window). A Degraded run never opens an incident, and neither does a run you start with Trigger Now. The incident closes by itself on the first passing run (a Degraded run passes too), or after the configured number of passing runs. It also closes when its check is deleted, and you can close it here with Resolve manually. Instead of isolated failed check results, Incidents groups each outage's start, end, duration, and failure reason into one row.
Checks configured on Uptime Monitoring: Checks are what generate incidents: nothing appears here until a check fails. An incident keeps the name its check had when the incident opened, so the incidents of a deleted check stay listed under that name, while the Check filter lists current checks only. On the uptime dashboards only the open-incident counts, such as the Open Incidents tile, include incidents. The uptime figures, such as Overall Uptime, are computed from the check results, so resolving an incident by hand does not change them.
Key concepts
- Incident - A record of the period during which a configured check was failing, from the failed run that opened it until it closes: when the check passes again or is deleted, or when an operator closes it manually. (related: Uptime Monitoring: Checks)
- Check - The monitored target and probe schedule that each incident on this page is generated from. (related: Uptime Monitoring: Checks)
- Resolution - How an incident was closed: Auto when the check recovered (or was deleted), or Manual when an operator resolved it by hand using Resolve manually.
- Status - Whether an incident is still ongoing (Open) or has ended (Resolved).
When to use it
- A check's reported uptime looks lower than expected and you need to see the specific failure windows behind it.
- You need to confirm whether a past outage closed itself (Auto) or still needs manual resolution.
- You're investigating a reported outage and need to narrow the history by check, status, or date range.
- An incident has stayed Open longer than expected and you've already confirmed the underlying problem is fixed.
- You're reviewing a check's incident history before changing its configuration on Uptime Monitoring: Checks.
Before you begin
- At least one check must be configured and running on Uptime Monitoring: Checks, since incidents are only created when a configured check fails.
- Know the check name or approximate date range you want to investigate, to use the Check, Status, From Date, and To Date filters effectively.
- Before using Resolve manually, confirm the underlying problem is actually fixed: the action only closes the incident record, it does not re-run the check.
- Resolve manually needs a role that may close incidents, such as UptimeAdmin, Ops or GlobalAdmin. Other roles see the button disabled, with a note on who can close the incident.
Common workflows
Filter the incident history for a specific check
Persona: load-test operator investigating an outage
- Select the check you want to investigate, for example Octans quarter-close burst, from the Check dropdown.
- Expect: The dropdown closes and the field shows the selected check's name in place of All Checks.
- Set From Date and To Date to the window you want to review, then select Apply.
- Expect: The table reloads showing only incidents for that check within the chosen date range.
Verify: The Check Name column shows only the selected check, and every Start Time falls inside the chosen date window. If the list is empty, no incident was recorded for that check in that range.
Manually close a stuck open incident
Persona: admin closing out a confirmed-fixed outage
- Select a row with Status = Open to open its Incident Details.
- Expect: A modal opens showing the check name, the failure reason, the endpoint, environment and tags when the check has them, and an End Time that reads Ongoing.
- Select Resolve manually in the Incident Details modal.
- Expect: A Resolve incident manually confirmation prompt appears: Close this incident now? The next failed check on this target will open a new incident.
- Select Resolve to confirm.
- Expect: The incident's Status changes to Resolved and its Resolution changes to Manual; the modal closes and the table reflects the updated row.
Verify: The row's Status column now reads Resolved and its Resolution column reads Manual. If the check fails again later, a new incident row opens for it rather than reopening this one.
Steps
Step 1
Open the Incidents page.
Expected result: The incident history table loads with the Status, Check Name, Failure Reason, Start Time, End Time, Duration, and Resolution columns, and the Check, Status, From Date, and To Date filters appear above it.
This gives you a starting view of every automatically detected outage before you narrow it with filters or open a specific incident for detail.
- The Check filter defaults to All Checks and Status defaults to All, with no date range applied.
- Rows are listed with the most recent Start Time first.
- The list refreshes by itself when an incident opens or closes.
- When no incident matches the filters, the page shows No incidents found.
Field reference
| Field | Purpose | Format / Validation | Required | Default |
|---|---|---|---|---|
| Check | Narrows the table to incidents for one monitored check. Keep the default All Checks to scan every check at once, or pick a specific check to review just its outage history in isolation. | Dropdown list of configured check names | No | All Checks |
| Status | Narrows the table by incident state. Choose Open to find outages that are still unresolved and may need attention, Resolved to review closed outages, or leave All to see both. | Dropdown: All, Open, Resolved | No | All |
| From Date | Sets the earliest incident start date to include. Leave it blank to include incidents from the start of recorded history, or set it to shrink the table to a recent investigation window. | dd/mm/yyyy | No | - |
| To Date | Sets the latest incident start date to include. Leave it blank to include incidents up to the present, or pair it with From Date to bound a specific reporting period. | dd/mm/yyyy | No | - |
Column reference
| Column | What it shows | How to read it |
|---|---|---|
| Status | Shows whether the incident is still active or has ended. | Open means the check that started this incident has not recovered yet; Resolved means the incident closed: the check passed again or was deleted, or an operator closed it manually. |
| Check Name | Identifies which configured check this incident belongs to. | Use it to confirm which target produced the outage before cross-referencing that check's configuration. |
| Failure Reason | Describes why the check failed, in the check's own error message. | Read it to classify the cause, for example a timeout, a DNS resolution failure, or a TLS handshake failure, before deciding whether to escalate. |
| Start Time | Marks the failed run that opened the incident. | Compare it against your own monitoring or alerts to confirm the outage window recorded here matches what you observed. With Retry Count or Time Window, the check had already failed before this time. |
| End Time | Marks when the incident closed: the passing run that closed it, the moment the check was deleted, or when an operator closed it manually. | Together with Start Time it defines the Duration column; it stays unset while the incident is still Open, and the Incident Details show Ongoing. |
| Duration | Shows the elapsed time between Start Time and End Time. | Longer durations mean longer outages; use it to rank incidents by severity when triaging several at once. |
| Resolution | Shows how the incident was closed. | Auto means a passing run closed the incident without intervention, or its check was deleted; Manual means an operator closed it using Resolve manually before the check recovered on its own. |
The Incident Details modal also shows these fields when they apply:
| Field | What it shows | How to read it |
|---|---|---|
| Monitored signals | Shown for Azure Function checks only: the HTTP response and the function invocations as they were when the incident opened. | Use it to see which signal failed, beyond the summary given in Failure Reason. |
| Endpoint | Shows the address or URL the check was probing, when the check has one. | Confirms the exact target affected, useful when a check name covers more than one endpoint. |
| Environment | Shows which environment the check targets, when one is set. | Helps you separate production outages from staging or test environments when triaging several incidents. |
| Tags | Shows the labels inherited from the check's configuration, when it has any. | Use tags to see which team, service, or category the affected check belongs to. |
Controls reference
Apply
Re-queries the incident list using the current Check, Status, From Date, and To Date filter values.
When to use: Use it after setting one or more filters to narrow the table to the incidents you're investigating.
Side effects: Read-only: changes only which rows are displayed, not any incident data.
Clear
Resets the Check, Status, From Date, and To Date filters to their defaults (All Checks, All, blank dates) and reloads the full incident list.
When to use: Use it to return to the unfiltered view, or when a filter combination returns no rows and you want to start over.
Side effects: Read-only: restores the default view and does not change any incident.
Select an incident row
Opens the Incident Details view for that row, showing the status, check name, failure reason, the endpoint, environment, and tags when set, the monitored signals for an Azure Function check, and the start time, end time, and duration.
When to use: Use it when the table's summary columns aren't enough to understand an outage's full context.
Side effects: Read-only: only displays additional detail, does not change the incident.
Resolve manually
Closes an Open incident immediately once you confirm the prompt, setting its Status to Resolved and its Resolution to Manual. The button is in the Incident Details of an Open incident. It needs a role that may close incidents, such as UptimeAdmin, Ops or GlobalAdmin; other roles see it disabled, with a note on who can close the incident.
Side effects: Mutating: changes the incident's Status and Resolution. Your alert profiles send no recovery alert for it. A new, separate incident opens the next time this target's check fails.
Verify the result
After filtering, the table lists only incidents matching your Check, Status, and date criteria, and the row count reflects that narrower set. Opening a row shows its full Incident Details, including the endpoint, environment, and tags recorded for that outage. If you resolved an incident manually, its Status reads Resolved and its Resolution reads Manual instead of Auto, and it drops out of the list if you then filter Status to Open. If the table still shows every incident after setting a Check filter, confirm you selected the intended check name and selected Apply.
Troubleshooting
- Symptom: The incident list is empty after selecting a check and date range. Fix: Select Clear to reset the filters, then confirm the check actually failed in that period on Uptime Monitoring: Checks before narrowing the range again.
- Symptom: An incident you expect to see does not appear in the table. Fix: Check whether the Status filter is set to Open or Resolved rather than All; an incident in the opposite state is hidden until you switch it back to All.
- Symptom: Resolution shows Auto for an incident you thought you had to close manually. Fix: The check likely recovered on its own before you acted; Auto means a passing run closed it (or its check was deleted), not that no one noticed.
- Symptom: Resolve manually is missing or disabled. Fix: The button shows only on an incident that is still Open. When it is disabled, your role cannot close incidents by hand; the note next to it names the roles that can.
- Symptom: An incident stayed Open through a maintenance window. Fix: A maintenance window pauses the check, so no run closes the incident during the window. It closes on the first passing run after the window ends, or you can resolve it manually.
- Symptom: Start Time and End Time look off by several hours compared to your own records. Fix: This page and your records may use different time zones. Convert both to the same zone before comparing them against raw check logs or external monitoring.
Related articles
- Prerequisite: Uptime Monitoring: Checks - checks must be configured and running before they can open incidents here
- See also: Uptime Monitoring: Maintenance - scheduling a maintenance window keeps planned downtime from generating new incidents
- See also: Uptime Monitoring: My dashboard - summarizes current uptime status, which reflects open and resolved incidents
- See also: Uptime Monitoring: Dashboards - visualizes uptime and incident trends across checks over time