Read monitor results and history
Current health comes first
Open Monitors, then select a monitor. The state near the monitor name answers what Uptime currently knows.
| State | Meaning | Suggested action |
|---|---|---|
| Operational | Recent checks satisfy the healthy policy | No immediate action |
| Degraded | Evidence suggests partial or unstable behavior | Review recent regions and checks |
| Outage | The incident confirmation policy has been reached | Open the incident and begin response |
| Maintenance | The monitor is inside planned work | Confirm the schedule and affected components |
| Paused | New checks are not being scheduled | Resume it when monitoring should continue |
| Pending | Uptime is waiting for enough initial evidence | Wait for the selected regions to report |
A failed check is not always an outage
A check is one attempt from one location. An incident is a higher-confidence conclusion based on the thresholds and regions you selected.
One check can fail because of a temporary network route, a slow reply, a changed keyword, or a local provider issue. Uptime keeps that evidence visible without automatically treating every failure as customer-wide downtime.
Current health, history, and exact evidence
Use the summary for context, then open an exact check or event when you need the cause.
Current state
99.98%
184 ms
Read the availability bars
The activity strip provides a compact history. Hover a segment for its date and state. The preference under Settings → Preferences controls how many days appear on both the dashboard and monitor list.
The strip is a summary, not a stopwatch. For the exact start and end of an event, use the detailed chart or open the incident.
Use the performance chart
Choose a range that matches your question:
- 1h, 6h, or 12h for something happening today;
- 24h or 7d for recent patterns;
- 30d or 90d for trends and reporting.
The chart uses larger time buckets for longer ranges so it remains fast. That means a short event may appear as a narrow marker rather than a wide colored block.
Average, median, and p95
- Average adds all response times and divides by the number of checks.
- Median is the middle result and represents a typical check.
- p95 is slower than most results and helps reveal poor experiences hidden by an average.
Start with average. Compare median and p95 when the chart looks stable but some users still report slowness.
Understand the Events row
The Events row aligns operational context with the chart.
- An incident marker identifies unexpected confirmed impact.
- A maintenance marker identifies planned work.
- Hovering an event shows its title, state, and exact time.
- Selecting an incident opens its complete history.
Maintenance can also appear as a neutral chart overlay to show which response-time data occurred during planned work. It should never use the same visual treatment as an unexpected outage.
Compare regions
Regional comparison shows whether one location behaved differently. If US East failed but US West and Europe passed, the service may have a local route or edge problem rather than a worldwide outage.
Local impact can still be real. Use the evidence to describe the affected audience accurately instead of assuming either “everything is down” or “nothing is wrong.”
Open the check log
The check log is the most detailed evidence view. Filter it by time, status, and region rather than scrolling through every observation.
Each row can include:
- when the check ran;
- which region ran it;
- whether it passed;
- how long it took;
- the protocol result;
- a safe failure explanation.
Use the check log when you need to answer “what exactly failed?” Use the incident timeline when you need to answer “what did our team do about it?”
Use Compare carefully
The optional previous-period comparison places the preceding equivalent range beside the current one. For example, comparing seven days uses the seven days immediately before the current range.
Compare is useful for questions such as:
- Is response time slower than last week?
- Did a deployment change normal performance?
- Is the current pattern unusual?
It does not compare two arbitrary dates and it does not change incident calculations.
A simple investigation routine
Confirm the exact time
Use the event hover or failed check timestamp. Avoid relying on the visual width alone.
Read the failure reason
Identify whether it was connection, timeout, DNS, TLS, status, or assertion related.
Compare locations
Check whether one region or several regions saw the same problem.
Check operational context
Look for a deployment, maintenance window, provider notice, or another monitor failing at the same time.
Open the incident when confirmed
Use the timeline for acknowledgment, updates, notifications, and resolution.
Continue with Troubleshoot a failed check or Respond to an incident.