Status History for Services in the Status Module

[dschipfel]

Hello FreeITSM Team,

I would like to suggest an enhancement for the Status module that would significantly improve transparency and troubleshooting capabilities.

Current Situation

At the moment, the Status module only shows the current status of a service. While this is useful for getting a quick overview, there is no way to see how the status has changed over time.

As a result, it is difficult to answer questions such as:

• When did a service become unavailable?
• How long did an outage last?
• How often has a service experienced issues in the past?
• Was the service already degraded before the incident was reported?

Proposed Enhancement

Add a status history for each service that records all status changes over time.

The history could include:

• Previous status
• New status
• Date and time of the change
• Duration of the status
• Optional comment or reason for the change
• User or system that performed the update

Benefits

• Improved troubleshooting and root cause analysis
• Better visibility of recurring service issues
• Easier reporting and auditing
• Greater transparency for administrators and service owners
• Ability to review past outages and maintenance windows

Additional Ideas

A graphical timeline or uptime chart would make the feature even more valuable. For example, administrators could quickly see:

• Uptime percentage
• Number of incidents per period
• Service availability trends
• Historical outages and maintenance events

Example

When opening the status page of a service, I would like to see not only that the service is currently Operational, but also:

Date/Time Status Duration
2026-08-08 14:10 Degraded Performance 2h 15m
2026-08-08 16:25 Operational Current
2026-08-01 09:30 Major Outage 45m

This would provide valuable context and make the Status module much more useful for operational monitoring and incident reviews.

Thank you for considering this suggestion. I would be interested to know whether a status history feature is already planned or if there are existing plugins or workarounds available.

Best regards, Daniel

[edmozley]

Thanks Daniel @dschipfel, this is in main now, and it covers everything on your list.

Every service on the status board has a History and uptime link. It shows a day-by-day strip for the last 7, 30, 90 or 365 days, the percentage of that period the service was available, and each period it spent at a given impact level with how long that lasted. Incidents also keep a running thread of updates: the time, the status, the comment, who made the change, and which services were at which level at that moment.

One thing worth explaining, because it shaped the whole design. There is no status field on a service to keep a history of: a service's status is worked out live as the worst impact among its open incidents. So rather than adding a log that would start empty, the history is derived from the incidents you already have. That means it covers outages that happened before the feature existed rather than becoming useful in six months.

The flip side is that the figures are only as good as the way incidents are recorded, so that is what the documentation concentrates on:

• Service uptime and history
• Service uptime and history: Developer Guide

The first page works through the case that matters most: a three-day outage taking out four services, brought back at four different times. It shows exactly what you do at each point and what each service then reports. Printing came back after nine hours, the VPN went from Major Outage to Degraded before recovering, and each of the four ends up with its own accurate downtime rather than all of them inheriting "three days". Those figures are not illustrative, by the way. That scenario was built through the real save endpoint as the test for the feature, so the table is what the code actually produced.

Two decisions you may want to change for your own installation:

Planned maintenance does not count against uptime by default. Whether time counts is set per impact level, on Settings > Impact levels, so any level you add yourself is asked the question when you create it. Counting maintenance makes a well-run service look worse than a neglected one, which is why it is excluded to begin with, but it is a checkbox if you disagree.

Customers do not see uptime figures unless you turn that on. A percentage is a stronger statement than a status dot, so Settings > Uptime keeps portal visibility off until you decide otherwise. That tab also sets the default period.

The one thing not done yet: recovery times are recorded as "when you saved the update", not "when the service actually came back", so there is no back-dating. Happy to add that if it turns out to matter in practice.

Would be glad to hear how the figures look against what you would have expected.

[dschipfel]

Thanks for the detailed explanation and for implementing this feature.

I really like the approach of deriving the history directly from incidents instead of introducing a separate service status log. The fact that historical incidents are automatically included makes the feature immediately useful instead of having to wait months for data to accumulate.

The history view, uptime calculations, and incident timeline cover everything that was on our original requirements list, so thank you for taking the time to implement it so thoroughly.

We will now test it in our day-to-day operations and compare the reported figures with our own expectations and historical incidents. From what I have seen so far, the concept makes a lot of sense and provides exactly the level of transparency we were looking for.

I also agree with excluding planned maintenance from uptime calculations by default. In our view, this is the right approach, as scheduled maintenance is often necessary to improve service quality and reliability.

We'll come back with feedback once we've gained some real-world experience with it. Thanks again for the great work!

[tjedelhauser]

Hi Ed,

there seems to be a bug related to renaming the "Operational" impact level. If I rename it to something else, the status page no longer picks up the change correctly, the service still displays the old label "Operational" and the green colour is gone, even though the underlying status should still map to that (renamed) level.

It looks like the label/colour isn't being resolved dynamically after the rename, so the status board falls back to a stale default instead of reflecting the current name.

Thanks,