Uptime

The bars under each component and the percentage beside them are the number your customers quote. So here is the whole of how it comes about.

It comes from your reports, not from measurements

Without a check of your own, we do not check your systems. Statuswerk then sends no requests to your servers and measures no response times. Uptime follows from how long your components spent in which state — and you set those states, by hand, through an incident, or through the API.

One exception: if a monitoring check belongs to the component and may switch it, the check sets those states itself — the component's uptime then comes from our measurements. A public check also shows its own measured uptime: the share of time without a confirmed outage.

That has an uncomfortable side and a comfortable one. Uncomfortable: a disruption you do not report does not show up in uptime. Comfortable: the number reflects what your customers actually noticed, rather than what a probe in a data centre saw.

The arithmetic

For any period we count the minutes per state:

downtime minutes = minutes in major outage
                 + minutes in partial outage × 0.3

uptime %         = 100 − (downtime minutes ÷ minutes in period) × 100

Three things stand out:

A partial outage counts at 30%. If part of your service works and part does not, that is not the same as everything being dead. An hour of partial outage costs 18 minutes.

Degraded performance costs nothing. Slow is not down. The state appears on the page and in the history, but it does not lower the number.

Maintenance is not downtime. Announced work is not a disruption. A component in Maintenance consumes no downtime minutes.

An example

A 90-day period, so 129,600 minutes. In it:

  • 2 hours of major outage → 120 minutes
  • 5 hours of partial outage → 300 × 0.3 = 90 minutes
  • 4 hours of maintenance → 0 minutes
  • 3 hours of degraded performance → 0 minutes

That is 210 downtime minutes, so 99.84%.

Two numbers that get confused

The page carries two different uptime figures, and they come about differently.

Per component — the bars under each component. They show the arithmetic above applied to that component's states. Unambiguous and directly traceable.

The combined chart at the top — "Accumulated uptime over all components". It is the average of the individual component figures, not a separate calculation over all downtime minutes together.

The difference matters more than it sounds. An example: twelve hours of major outage on one component.

  • With one component, the combined chart reads 50% for that day.
  • With four, three of them healthy, it reads 87.5% — the same outage.
  • With twenty components, 97.5%.

The more healthy components stand beside it, the better the same outage looks. That is unavoidable in an average, but you should know it before putting the number in an SLA. For a defensible statement about a single service, use the component's figure, not the combined chart.

The 0.3 weighting for partial outages, incidentally, is in both numbers — it is applied inside each component, and the combined chart inherits it through the average. There is no second weighting on top.

Only components that are visible and have Show uptime on enter the combined chart. What you hide does not count.

What you can configure

On the status page under Display:

  • Show uptime — hides bars and percentages entirely.
  • Show combined uptime chart — turns off only the chart at the top; the per-component bars stay. Useful when you dislike the average for the reasons above but want the individual components.
  • Uptime days — how far the bars reach back, between 7 and 365 days. The default is 90.
  • Degraded threshold — 99.50% by default. Below it the bar is red; above it but under 100% it is orange; at exactly 100% green. This is where you decide when a day counts as bad.

And per component:

  • Show uptime — individual components without bars.
  • Uptime start date — from when uptime counts. Without a date it starts when the component was created (or at its first recorded status change, if that is older). Days before that are grey, "No data yet", and count neither in the percentages nor in the platform uptime. Only set an earlier date if you kept the component somewhere else before — the days in between then count as 100%.

Excluding a single incident

An incident can be set to Do not count towards uptime. This applies retroactively: the bars are recalculated immediately, past days included.

It is meant for work too small to describe your service's availability honestly — not for making a bad week disappear. An uptime figure that hides everything inconvenient is worthless to your customers, and they notice.

Details under Unlisted entries.

Uptime through the API

curl https://statuswerk.eu/api/v1/statuspage/status \
  -H "Authorization: Bearer $STATUSWERK_TOKEN"

Returns the overall status, the number of open incidents and the page's uptime in percent (uptime, over the period the page shows; ?days=30 for another one, up to 365 days) — meant for CI pipelines and reports. Every component brings its uptime over the last 90 days under GET /api/v1/components (uptime_90d).