Service Status

Folder: service-status/ Colour: Emerald #10b981

Service health dashboard with incident-driven status tracking. Each service's current status is derived from the worst open incident affecting it.

Dashboard (index.php)

• Grid view of all active services, each card showing the worst current impact from open incidents
• Status levels: Operational (green), Degraded (amber), Partial outage (orange), Major outage (red), Maintenance (blue)
• Active and recently resolved incidents listed below the grid
• Create / edit incidents via modal with a multi-service impact selector — one incident can affect multiple services, each with its own impact level
• Actions column and right-click menu on every incident — edit, resolve in one click, delete, show updates

Acting on an incident

Each incident in the list carries an Actions column — Edit, Resolve and Delete — and the same actions are on the right-click menu, named rather than drawn, along with Show updates.

Action	What it does
Edit	Opens the incident: title, status, comment and affected services
Resolve	Sets it to the first status marked resolved, in one click
Delete	Removes the incident and its updates. No undo, so it asks first

Resolve sends only the status. The service treats an incident update as partial and keeps the current title, comment and affected services, so a one-click resolve cannot blank an incident. It goes through the same path as resolving in the modal, which means the resolution time is stamped, a line is added to the update thread so the history still reads properly, and the service_status.incident_resolved workflow event fires.

It is hidden on an incident that is already resolved rather than shown and inert. If no status is marked as resolved, it says so rather than guessing at a name — add one under Settings → Incident statuses and tick Resolved.

🔑 The title was always a link; it just did not look like one. That was the whole of discussion #100 — people could not tell there was a way in. The title is now underlined and stays clickable, so anybody who had already found it keeps the habit.

Internal notes and external updates

Saving an incident with something in the comment box adds an entry to its timeline, and you choose who that entry is for.

	Who sees it	For
Internal note	Your team only	What you are doing, what you have ruled out, which supplier you are chasing
External update	End users, in the self-service portal	What the people affected need to know

🔑 Internal is the default, and it resets to internal every time the dialog opens. Publishing is the deliberate act, and the choice is not carried over from the last incident you touched — otherwise you could publish because of a decision made an hour ago on something else.

🔴 Nothing reaches end users until an administrator switches it on under System → Service status on the portal. Until then, choosing external marks the update and the hint under the choice says plainly that nobody outside your team will see it yet.

⚠️ Everything written before this feature existed is internal, and stays internal. The column defaults that way, so running Database Verification cannot retroactively publish old troubleshooting notes.

Correcting an entry

Each entry has a correct and a remove action.

Correcting changes the words that are already there. Before this existed, fixing a typo meant saving the incident again, which posted the sentence a second time — so a reader saw it twice with the wrong version first.

You can also change who can see an entry after the fact: an internal note that should have gone out can be published without retyping it, and one published by mistake can be pulled back without losing the record that it happened.

⚠️ What an entry says about the status and the service impacts cannot be changed. Those are what was true at that moment, and rewriting them would make the timeline a record of what somebody wishes had happened.

What counts as an update

Saving an incident adds to the timeline only when there is something new to say — the status changed, the wording changed, or the affected services changed.

• Renaming an incident is not a new message.
• Opening one and pressing Save posts nothing at all.
• A status change with no new wording is recorded on its own, rather than repeating the previous sentence. Otherwise a reader gets "Investigating — we are aware of delays" followed by "Resolved — we are aware of delays".

Requested by dschipfel in discussion #99.

Planned maintenance (3.2.0)

For work you know about in advance - "Phone system move, Saturday 08:00 to 14:00".

Press Plan under Planned maintenance on the board. Give it a title, when it starts and (optionally) ends, what people should know, and the services it affects with an impact (Maintenance unless you pick another). Then:

When	What happens
As soon as you save	It shows as Upcoming on the board - and on the portal, if incidents are shown there. Nothing changes on the services: they stay green.
At the start	It becomes an ordinary incident on those services, dated from the planned start (even if nobody was looking at 08:00), with your words as its first external update and the status Identified. Its workflows run like any incident's. The row shows In progress and Open takes you to the incident.
At the end	The incident is resolved, dated at the planned end. Leave the end empty to resolve it yourself. If you resolve it early, your time stands.

Until it starts you can change it, or Withdraw it, with Edit. Once it has started it is an incident: change it there.

Maintenance does not count against uptime (the Maintenance level's own setting), so a planned outage never makes a well-run service look worse.

When is the start noticed? Whenever somebody opens the board, the portal or Watchtower, and on every run of the scheduled workflow job (cron/workflow_scheduled.php - see Time-Based Triggers). The incident is dated from the planned start either way; schedule the job if the services must change on time while nobody is looking.

A project can announce its disruption here from its Connections tab; the row then says which project it came from.

Why it is not simply an incident created early. An incident is "open" from the moment it exists - about fifteen places (the board, the portal, Watchtower, uptime, Report Packs, the REST API) decide so from its status, and none of them knows a start time. Created on Tuesday for Saturday, it would show the phones under maintenance for four days and count from Tuesday. So a plan waits in its own table and only becomes an incident when the work starts.

Status Derivation

A service's current status = the worst-impact open incident affecting it. When all incidents affecting a service are resolved, the service returns to Operational automatically. No manual "flip this service back to green" step.

A healthy service has no impact level stored against it at all — there is no incident, so there is nothing to record. Its status is worked out as the page is drawn, from the level marked as the default on the Impact levels tab. That level can be renamed and recoloured, and the board, the portal, Watchtower and the API all follow it. It did not always: that is issue #70, written up in full in Renaming an impact level.

History and uptime

Every service also carries a history: a day-by-day strip, an uptime percentage over 7/30/90/365 days, and each period it spent at a given impact level. It is derived from incidents rather than logged separately, so it covers outages that happened before the feature existed.

How you record an incident decides how accurate that history is — see Service uptime and history, which works through a three-day outage across four services brought back at different times. The Developer Guide covers the update log, the overlap arithmetic and the compatibility rule for incidents raised before it existed.

Settings (settings/)

Manage the list of services:

• Name
• Description
• Display order (drag-and-drop)
• Active flag

Self-Service Portal Integration

The Self-Service Portal dashboard pulls a live system-status panel from this module so end users can see at a glance whether their issue might already be a known outage.

With System → Service status on the portal switched on, it also shows the incidents themselves under What is happening, with the services each affects and a collapsed timeline of the updates marked external. Off by default: turning it on publishes incident titles, which were written for your team rather than for customers.

Watchtower Integration

The Watchtower attention card surfaces active incidents and degraded services.

Help

Interactive guide at service-status/help.php with left-pane navigation, scroll-spy, and 6 sections covering the status dashboard, status levels, managing services and incidents, incident history, settings, communication tips.

Key Tables

Table	Purpose
services	Service definitions
incidents	Incident records
incident_services	Many-to-many — which services each incident affects, with per-service impact level
incident_updates	Update timeline per incident
status_planned / status_planned_services	Planned maintenance not yet started (3.2.0) - becomes an incident at its start

On a phone

Service Status is one of the five modules built to work properly on a phone — the service board shows two services across so you can still take in the whole estate at a glance, and incidents become one card each rather than a four-column table. Nothing changes on the desktop. See Mobile: Service Status.

Incidents from Domains (3.0.0)

A service can be linked to the domains it runs on (a domain's Connections tab). When such a domain - or its certificate - expires, Domains → Settings → Service Status decides whether Domains does nothing, suggests the incident (a Raise incident button on the domain), or raises it by itself on its scheduled run. An incident raised that way is an ordinary incident: it is titled after the domain, opens with an internal update unless that setting says to publish, records the impact chosen there, and is resolved by Domains when the domain recovers (unless switched off). It is raised once per problem, never repeatedly. See Domains → Service Status.