Uptime Calculation and Shared Values
Uptime values can be a complete lie if they're not properly connected to monitoring. openstatus makes uptime transparent and configurable — you decide how it's calculated and which values to share on your status page.
When monitoring an endpoint, a check can end up in one of three states:
- Success — everything's fine.
- Degraded — slow or partially failing.
- Down — no response or full failure.
In the dashboard, two settings on the status page's Components page control this:
- Status source — where the status comes from:
- Monitor checks (default) — derived directly from your monitoring data.
- Reports only — only from the status reports and maintenances you publish.
- Card shows — what the hover card (and uptime) is based on, when the source is Monitor checks:
- Time per status — aggregated from the incidents' duration.
- Number of checks (default) — aggregated from every check result.
API and URL values: in the API, SDKs and configuration links, Monitor checks is
type: absolute, Reports only istype: manual, Time per status isvalue: durationand Number of checks isvalue: requests.
TL;DR
| Setting | Source of truth | What users see | Best for |
|---|---|---|---|
| Monitor checks + Time per status | Incident duration | Time-based uptime, proportional colours | Accurate long-term view |
| Monitor checks + Number of checks | Every check result | Check-based uptime % | Real-time reflection |
| Reports only | Your status reports and maintenances | Controlled, narrative updates | Transparency without monitoring |
Monitor checks
With Monitor checks as the status source (absolute), uptime is calculated from actual monitoring results. It's the most accurate reflection of what's really happening, and comes in two variants: time per status and number of checks. Both share real data with your users — incidents, degraded states, and historical uptime — but they differ in how they aggregate and display that data.
Time per status
The time per status value (duration) is calculated from the total monitoring time and the duration of incidents.
In simple terms: uptime = (total time - incident duration) / total time
This means uptime is based on how long something was down, not how many checks failed. Only incident durations are included in the calculation.
Temporary single-region ping failures (e.g., one location failing once, sometimes this just happens) are not propagated to users — because these often don't represent a real outage. That's also why we recommend at least three locations per monitor for redundancy.
The proportional colours in the status bar are drawn from these duration values. Hovering over a day shows both incidents and status reports, so users can explore what happened.
Number of checks
The number of checks value (requests) is more straightforward — it looks at each ping result individually. Every check we run contributes to your uptime score.
In simple terms: uptime = (success + degraded) / total requests
This is the current default mode for most openstatus users. It's simple, data-driven, and updates immediately as new results come in.
Like with time per status, hover cards display incidents and status reports, giving your users a quick overview of recent events.
Reports only
The Reports only status source (manual) is for teams who want to fully control what's shown on your status page, without relying on automatic checks. By default, your monitor is marked operational. You can then manually create status reports whenever you want to reflect changes — independent of any monitoring data.
This is ideal if:
- you don't have synthetic monitoring set up yet, or
- you're sharing updates that aren't tied to uptime (e.g., service degradation due to external dependencies).
In this mode, all displayed uptime values and statuses come from your shared report data, not from active pings.
In simple terms: uptime = (total duration - weighted status report duration) / total duration
How much a report counts against uptime depends on the component impact each update sets:
| Impact | Downtime weight |
|---|---|
operational / degraded_performance | 0 |
partial_outage | 0.5 |
major_outage | 1 |
A report that goes major_outage → partial_outage → operational across its updates counts each interval at its own weight.
Legacy behavior: reports without impact levels (created before component impacts existed, or via clients that don't send them) count their full duration as downtime —
uptime = (total duration - status report duration) / total duration.
Note: the values you define are attached to a status page. You cannot change them per monitor (for now).