Updated 25 October 2026 · By the Upcertain team
The problem with a raw incident list
Run a status page for a few weeks and the incident list fills with entries like "API was unavailable for 48 seconds". Each is true. Together they bury the outage that mattered, a 25-minute failure on Tuesday, under a wall of noise, and they make a reliable service look fragile.
Hiding short incidents is no better. Customers who saw an error and then find nothing on the status page stop trusting it.
Grouping what happened together
When a shared dependency fails, every service behind it goes down at about the same time. Monitors check on their own cycles, so they notice a few seconds apart: one at 09:14:03, another at 09:14:21. Listed separately, that is ten incidents. It was one event.
Upcertain shows incidents that start within 2 minutes of each other as one: "Web app, API and 8 more were unavailable", with the cause, the time range in the page's time zone and the duration. Expanding it shows a plain description, when it started and was resolved, and each affected service.
Each service's own downtime
A grouped event runs from the first failure to the last recovery. With several services, that span can be longer than any one of them was down, because each was noticed and recovered on its own cycle, up to a check interval apart. So the page also says how long each service itself was down: "lasted 1 m 2 s; each service down 46 to 48 s". The REST API and MCP server report the same per-service durations.
Folding brief outages
The owner of each page chooses what counts as brief: 1, 2, 5, 10, 15 or 30 minutes, 5 by default. Ongoing incidents and anything longer get their own card. A day's brief ones fold into one expandable line:
6 brief outages · each under 5 minutes · 7 m 30 s in total
Nothing is lost. The line expands to every incident, the total time is right there, and uptime still counts every minute.
Hiding them, honestly
Some teams prefer to leave brief outages off the page entirely. That is an option, with one rule we would not give up: the page says how many were not listed. Uptime figures still include them. A reader can always see that something was left out and how much.
History by month
The main page covers the last 7 days, grouped by day in the page's time zone. A history page shows 90 days of incidents, one month at a time, with the same grouping and folding.
What we learned building it
- Grouping needs a window. Two minutes catches services failing together on 30-second and 60-second cycles without merging unrelated incidents.
- Durations confuse people when they disagree. Showing both the event span and each service's downtime made the timing easier to read.
- "Brief" depends on the business. A 4-minute outage is brief for a documentation site and serious for a payment API, so the threshold is the page owner's choice.
You can see it on our own status page, and set it up from your monitors in a few minutes: status pages.