Uptime Status Page — Service History Bars HTML CSS

A public status page exists to answer one question fast — "is it just me, or is the whole service down?" — and the format every major status page (Statuspage, Better Uptime, Cachet) converges on is the same: a banner summarizing overall health, and a row of tiny colored bars per service showing recent history at a glance. This snippet builds that exact pattern in plain HTML, CSS, and vanilla JavaScript.

History bars as data, not images

Each service renders 90 thin <div> bars in a flex row, one per day, colored green/amber/red for operational/degraded/outage. genHistory() generates a randomized history that's mostly green with rare amber and red days, and the *last* bar always reflects the service's actual current status — so the simulated history stays consistent with the live status shown in the row above it. Replace genHistory() with real incident data and the rendering needs no changes.

Hover tooltips without a tooltip library

Each bar carries its day-relative label and status in a data-tip attribute, and a pure-CSS ::after pseudo-element reads it via content: attr(data-tip) on hover — no JavaScript positioning logic and no extra DOM nodes per bar, which matters here since there are 90 bars × however many services. This is the same zero-JS tooltip technique used for lightweight hint text throughout this library.

Uptime percentage, computed from the bars themselves

uptimePct() doesn't take a separate "99.9% uptime" number from anywhere — it counts how many of the 90 generated bars are operational and divides by the total. This guarantees the displayed percentage and the visual bar row can never contradict each other, which is a real bug class in hand-maintained status pages where the number and the history graphic are updated separately and drift apart.

Aggregated overall status

The top banner doesn't just say "operational" by default — updateOverall() reduces every service's status to find the *worst* one present (outage beats degraded beats operational) and reflects that exact severity in both the banner's color and its message. A single degraded service is enough to turn the whole banner amber; a single outage turns it red — exactly how users expect "is everything okay?" to be answered.

Why a status page exists separately from internal monitoring

Internal dashboards (Grafana, Datadog) are built for engineers diagnosing a problem; a public status page is built for everyone else asking one question fast. Keeping it as its own simple, low-dependency page — rather than exposing the internal monitoring tool directly — also means it can stay up and informative even during an incident that's affecting other parts of the infrastructure, which is exactly the moment a status page matters most.