Document service uptime and history, as a pair Plain-language page for whoever runs the status board, and a developer guide covering the derivation, the phase-2 update log and the arithmetic. The worked example Ed asked for is the centrepiece of the plain-language page: a three-day power failure taking out four services, brought back at four different times, with what you actually do at each point and what each service then reports. Those figures are not illustrative — the scenario was built through the real save endpoint as the test fixture, so the table is what the code produced. It also states the thing the feature depends on and which no amount of UI can convey on its own: the history is only as good as the way incidents are updated. Hence the contrast at the end between five saves giving four accurate service histories, and one save at each end giving one blunt figure that is wrong for three of the four. The developer guide records the two compatibility rules that are easy to get wrong later — returning null rather than an empty array for a pre-log incident, and omitting the EXISTS clause entirely when the tables are absent — plus the bug the worked example caught, where a restored service disappeared from its own history because the query still keyed off the current links. Linked from Service-Status and the sidebar.