The headline badge
The badge at the top (“All systems operational”) is the page’s current state. It is built in two steps. Step 1: roll up the metrics. Every metric bound to the page has a current status. The page takes the worst one. Severity is ordered: unhealthy, then degraded, then healthy, then unknown. One unhealthy metric outweighs any number of healthy ones. A page is only as healthy as its worst component, so averaging would hide problems. Step 2: fold in incidents and maintenance. An open incident or a running maintenance window can make the headline worse than the metrics say, never better. If every metric is green but you have published a major or critical incident, the headline shows the incident. The rationale: an operator who declares an incident knows something the probes do not yet see, and visitors should hear the human first. The same escalated verdict is used everywhere the overall status appears: the main page, the incident history page, the embed widget, the badge image, the JSON API, and the feeds. One calculation, many surfaces, so no two views of your page can disagree.Per-metric status
Each check produces a value, and the value is compared against your thresholds:- If it matches the healthy rule, the metric is healthy.
- Otherwise, if it matches the unhealthy rule, it is unhealthy.
- Otherwise it is degraded, the space between your two lines.
Dwell: why the page does not flicker
A single bad probe does not change the page. When a metric’s status would change, the new status has to hold for a configured dwell window before the page flips. Getting worse and getting better can have different windows, so you can flip to unhealthy quickly but demand a longer stretch of good readings before declaring recovery. While a change is dwelling, the page keeps showing the old status. The rationale is simple: a status page is a communication channel, not an oscilloscope. Visitors should see conditions, not noise.No data is its own honest state
When a check produces no value (the target is unreachable, the query returned nothing), the sample is recorded as no data rather than being guessed either way. By default that renders as its own neutral state, because Observer refuses to claim health it did not measure. For some metrics silence genuinely means good news. An error-rate check that produces nothing usually means there were no errors. Each metric therefore has a no-data treatment: leave it as no data, or fold it to healthy, degraded, or unhealthy. The fold applies to the current status and to history, with two exceptions it never touches:- Days before the metric existed. The strip stays neutral before the first sample ever recorded. A new check cannot retroactively claim a month of health.
- Hours that have not happened yet. Today’s bar fills as the day progresses. Nothing colors the future.
Delayed: when the data is stale
If a metric’s agent stops reporting, the last stored status would silently freeze. Instead of asserting a stale verdict, the page marks the metric Delayed once the last sample is older than a few push intervals. Delayed metrics are excluded from the live rollup, and a group whose every metric is delayed reads Delayed rather than pretending to know. The headline says “monitoring delayed”, which is the true condition: the target may be fine, Observer just cannot see it right now. Staleness is applied both when the page is read and by a periodic sweep that marks the stored status as no data. No alerts fire from staleness on the metric itself; the operator gets an agent-offline alert instead, because the broken thing is the pipeline, not the service being watched.The 30-day bars
Each metric shows one bar per day. A day’s color is decided by the worst thing that happened in it, hour by hour: the day is divided into 24 slots, each slot carries the worst status seen in that hour, and the day summarizes the slots. Hovering a bar shows the hourly breakdown and any incidents posted that day. Days with no samples inside the metric’s lifetime count as no data (or its treatment). Days before the metric existed stay neutral. The current day only contains the hours that have already passed. Group summary mode collapses a group to one bar per day, taking the worst status across all the group’s metrics for each day.Uptime percentages
The uptime number is the share of known days that were not unhealthy over the visible window. A degraded day still served traffic, so it counts as up. Days without data are not counted against uptime, and also not counted for it: an unmeasured day is excluded from the calculation entirely rather than being treated as up or down.SLOs and error budgets
An SLO is a public promise: this metric will be healthy some percentage of the time over a rolling window. The error budget is the allowance the target leaves. A 99.9% target over 30 days allows about 43 minutes of not-healthy; the page shows how much of that allowance remains. Budgets are computed from the same recorded samples the bars use, so the promise and the history can never tell different stories. Two protections keep the number honest:- Cold start. A freshly created SLO shows “collecting” instead of a number until its metric has at least a full day of observation. With ten samples, one bad reading swings the result violently in either direction; neither the resulting panic nor the false comfort is real information.
- Staleness. While the metric is Delayed, the budget shows no value rather than continuing to count unmeasured time for or against the promise.