Service Uptime and History

Service uptime and history

Every service on the status board carries a history: a day-by-day strip, an uptime percentage, and the outages behind it. This page explains how to read it, and — more importantly — how to record an incident so that the history comes out right.

💡 The one thing to take away. The history is not a separate log you maintain. It is worked out from your incidents. So the accuracy of every figure depends on updating an incident as things change, and that is what most of this page is about.

---

What you get

Open History and uptime on any service card:

• An uptime percentage for the last 7, 30, 90 or 365 days
• A day-by-day strip — one cell per day, so a bad week is visible at a glance
• Every period the service spent at a given impact level, with how long it lasted

Because it is derived from incidents rather than logged separately, it already covers outages that happened before this feature existed. A service you have been tracking for a year has a year of history the moment you upgrade.

---

Reading the strip

Colour	Means
Green	No incident touched the service that day
Red	An incident that counts against uptime. The colour is the impact level — hover to see which
Grey	An incident touched it, but at a level that does not count — planned maintenance, typically. Hover to see the actual level

⚠️ A service showing far worse uptime than you expect is usually an incident nobody resolved. An open incident counts until it is closed. Check the incident list before assuming the figure is wrong.

---

What counts as downtime

Each impact level decides for itself, on Settings → Impact levels:

Level	Counts by default
Major Outage	✅ Yes
Partial Outage	✅ Yes
Degraded	✅ Yes
Maintenance	❌ No
Operational	❌ No
No Disruption	❌ No

Planned maintenance is excluded deliberately: counting it makes a well-run service look worse than a neglected one. Any level you add yourself counts until you say otherwise, which is the safe way round.

The measurement period and whether customers see the figures live on Settings → Uptime. Portal visibility is off to begin with — a percentage is a stronger statement than a status dot, and once customers can see it, it reads as a published figure.

---

Recording an incident so the history is right

Each time you save an incident, FreeITSM records a snapshot of which services were at which level, timestamped. A service counts as down from the moment a snapshot puts it at a counting level, until the next snapshot says otherwise.

So there are three moments that matter:

1. Raise the incident with every affected service and its impact level. That is the start.
2. Save it again each time something changes — a service degrades, improves, or comes back. Change that service's level, or take it off the incident once it is fully restored.
3. Resolve the incident when everything is back. That is the end for anything still listed.

That is the whole technique. The rest of this page is one worked example of it.

---

Worked example: a three-day outage affecting four services

This is a real scenario run through FreeITSM, with the figures it actually produced.

The situation. Power is lost to a rack row on Sunday morning. Email, VPN, File Services and Printing all go down. They come back at different times over the next three days.

What you do, and when

Sunday 09:00 — raise the incident

Create an incident, status Investigating, and add all four services at Major Outage:

"Power lost to rack row B. All four services affected."

Sunday 18:00 — printing comes back

Open the incident, set status Identified, and remove Printing from the affected services. Leave the other three where they are.

"Generator online. Printing restored."

Monday 12:00 — the VPN is usable but slow

Change VPN from Major Outage to Degraded. Leave Email and File Services on Major Outage.

"VPN back on reduced capacity. File services still rebuilding."

Monday 20:00 — the VPN is fully back

Remove VPN from the incident.

"VPN at full capacity."

Tuesday 10:00 — file services restored

Remove File Services. Only Email is still listed.

"File services restored from replica."

Tuesday 15:00 — everything is back

Set the status to Resolved.

"Mail queues drained. All services restored."

What each service then reports

Six saves, one incident — and each service gets its own accurate history:

Service	Down from	Until	Recorded as
Printing	Sun 09:00	Sun 18:00	Major Outage — 9h
VPN	Sun 09:00	Mon 12:00	Major Outage — 1d 3h
	Mon 12:00	Mon 20:00	Degraded — 8h
File Services	Sun 09:00	Tue 10:00	Major Outage — 2d 1h
Email	Sun 09:00	Tue 15:00	Major Outage — 2d 6h

Over a 7-day window that gives:

Service	Downtime	Uptime
Printing	9h	94.64%
VPN	35h	79.17%
File Services	49h	70.83%
Email	54h	67.86%

Note what the VPN row shows: two periods, not one. A day and three hours completely down, then eight hours degraded. Both count against uptime, but the history records what actually happened rather than flattening it to a single level.

Why this beats the obvious alternative

The tempting shortcut is to raise one incident, leave it alone for three days, and resolve it at the end. That produces:

All four services: down for 3 days. Uptime 57% each.

Which is wrong for three of the four. Printing was fine after nine hours. Updating the incident as things changed is what turns one blunt figure into four accurate ones — and it costs five saves.

You do not have to remove services one at a time. But if you do, each one stops counting at that moment rather than when the incident is finally resolved. That is the difference between "the file server was down for two days" and "everything was down for three".

---

The incident's own thread

Every one of those saves also becomes an entry on the incident, under Updates in the incident list — the time, the status, who made the change, the comment, and which services were at which level at that point.

That is the running commentary a status page normally has, and it is the same data the per-service history is built from. Writing a sentence in the comment box each time you save is what turns a set of timestamps into something a manager can read afterwards.

---

Things worth knowing

• Incidents raised before this feature have no update thread. They still appear in the history, measured from when they were raised to when they were resolved — just without the detail in between.
• Overlapping incidents are not double-counted. Two incidents taking the same service down at once is one outage.
• An outage that started before the period you are viewing still counts for the part that falls inside it.
• Removing a service from an incident does not delete anything. The period it was down is already recorded.

---

Related pages

• Service Status — the module as a whole
• Service uptime and history — Developer Guide — how it works underneath
• Mobile-friendly Service Status