openstatus logoDashboard

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 is type: manual, Time per status is value: duration and Number of checks is value: requests.

TL;DR

SettingSource of truthWhat users seeBest for
Monitor checks + Time per statusIncident durationTime-based uptime, proportional coloursAccurate long-term view
Monitor checks + Number of checksEvery check resultCheck-based uptime %Real-time reflection
Reports onlyYour status reports and maintenancesControlled, narrative updatesTransparency 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:

ImpactDowntime weight
operational / degraded_performance0
partial_outage0.5
major_outage1

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).