Our status page could have shown a smooth average. It does not. Each public service gets ninety days of history, and each day is coloured by its worst event. This piece explains why we chose that rule, and how to read the history with it in mind.
The rule in one line
A day takes the colour of the worst thing that happened in it. If a service ran cleanly for twenty-three hours and had trouble for one, the day shows the trouble. Nothing is averaged away.
That makes the page look worse than an average would. We accept that. The page exists to tell you what happened, not to make us look steady.
Why not an average
Averages are kind to the people running a service. They are less kind to the people using it. If you were the one trying to reach a service during its bad hour, the other twenty-three hours did not help you.
An average also hides patterns. A short problem every few days can disappear into a high number. When each day shows its worst moment, a run of small problems is visible as a run of marked days. You can see it at a glance and ask why.
Slowness counts
A service can be up and still not be usable. If it takes too long to answer, you feel that as a problem even though nothing is technically down.
So slowness is an event in its own right. A slow day does not show as a clean one. If we only recorded whether a service answered at all, we would be reporting a better day than you had.
Maintenance counts too
Planned work is still time when a service may not behave as you expect. We record maintenance as an event rather than leaving it off the history.
That way a marked day is never a mystery you have to explain to yourself. Some trouble is planned and some is not, and the page does not pretend either kind away.
How to read ninety days
Ninety days is long enough to see habits, not just incidents. A few ways to use it:
- Look for clusters. One marked day is an event. Several close together suggest something worth watching.
- Read the colour as a ceiling. It tells you the worst thing that happened that day, not how long it lasted.
- Compare services side by side. If one service is marked often and another rarely, that difference is real information.
- Check the recent end first if you care about using a service today, then scan back for context.
What the page does not tell you
We would rather state the limits than let you assume more than the page shows.
- It covers public services only. Anything not public is not on it.
- A day's colour does not say how long an event lasted or how many people it affected. A short blip and a long problem of the same kind look the same at the day level.
- The window is ninety days. It shows recent history, not the whole life of a service.
- It says whether a service is up and behaving. It does not say how far a project has come.
That last point matters. Progress lives elsewhere on the site. Each project is split into modules marked shipped, building, next or later, and the percentages are counted from those marks, never typed. A service can be fully up while the project behind it is still building. The two measures answer different questions.
Where it fits
Atheron Progress has two halves. The tracker shows what we have built, computed from our repositories. The status page shows whether public services are up. The changelog and roadmap are the record that ties them together.
We chose the worst event rule for the same reason we count percentages instead of typing them. If the number can flatter us, it will drift toward flattering us. A rule that cannot be softened is easier to trust, for you and for us.
If a day on the status page looks bad, that is the page doing its job.
