Summary

  • AFRINIC’s status overview currently reports operational and says “All systems are go!”
  • Notice 502905, opened on 3 July 2026 for the AFRINIC website, remains present and recovering, has no ended_at value and contains only its original investigating update.
  • The two website components attached to that notice are themselves marked operational, while the public history presents a resolved 20 June event as the last incident.
  • This does not prove a current outage. It proves that the public projections do not close the same event together. AFRINIC needs a machine-readable closure receipt that reconciles page, component, notice and history state.

Green is usually the least ambiguous colour on an operations page. At AFRINIC, it currently sits beside an event that has not finished.

The simple status endpoint identifies the page as operational and supplies the sentence “All systems are go!” The component endpoint agrees. “AFRINIC Web Sites” is operational. So is www.afrinic.net. Yet the notice endpoint keeps record 502905 in the present tense. It classifies the unplanned event as recovering, leaves ended_at null and shows one update: the investigating message published on 3 July 2026, when AFRINIC said a technical issue had led it to take the website offline as a precaution.

The issue here is not whether the homepage loads today. A successful browser request would answer reachability at one moment, not the lifecycle question recorded by the status service. Nor is the open notice proof that the website remains unavailable. The narrow fact is more useful: four public representations that readers are invited to treat as one operational account have diverged.

The page summary says normal. The affected components say normal. The notice says recovery is still in progress. The history treats a different, resolved 20 June website issue as the last incident. A machine can retrieve all four statements without leaving AFRINIC’s own status domain, but it cannot infer an authoritative closure from them.

A status page is a state machine, not a noticeboard

Operational status looks like communication, but its harder function is accounting. An incident moves through states. It begins, gains a scope, affects components, receives observations, changes from investigation to mitigation or recovery, and eventually closes. The page-level colour is a projection of that underlying record. History is another projection. Subscriber messages are another. If those surfaces can move independently, “green” becomes a presentation choice rather than the result of a traceable transition.

AFRINIC’s own June event shows what a closed sequence can look like. The AIS 2026 website issue began with an investigating update. A later update says the incident had been resolved, and the record carries an end time. The July record does not. It has a beginning and an affected scope, but no public final observation, closure decision or end timestamp.

That comparison must remain bounded. The June and July events need not share a cause, duration or response. The June entry does not tell us what happened internally in July. It simply demonstrates that the public platform can store an explicit closing state. The absence of that state on notice 502905 is therefore not an unavoidable limitation of the medium.

The API documentation sharpens the distinction. It describes the simple overview as a way to obtain overall status without the complexity of components and notices. Simplicity is valuable only if it is a defensible compression. A page-level operational state can legitimately mean that all observed services are presently reachable even while an incident record awaits administrative closure. But if that is the rule, the API should expose it. Otherwise, a consumer cannot know whether the open event is a stale record, an intentionally continuing recovery or an exception that the overview calculation excludes.

Present service and incident closure answer different questions

The most charitable interpretation is also the most plausible: the website recovered, the component state returned to operational, and the incident record was not completed. That would make this a records problem rather than a continuing service problem. But a public status system should not require charity to select among mutually inconsistent states.

“Is the website responding?” is an observation question. “Has the incident ended?” is a decision question. Recovery evidence may support both, but it does not collapse them. A component can become operational after a successful check while an incident remains open for monitoring. An incident can be closed only after an owner accepts the evidence, records residual risks and issues the final update. Page colour may switch before that decision, but the relationship should remain visible.

This matters because different consumers ask different questions. A user deciding whether to retry a page mostly needs current reachability. A network operator automating dependencies may need component state plus the time and method of the observation. A member reviewing a disruption needs the event chronology. A board or auditor needs to know who accepted recovery and on what evidence. One green word cannot answer all four, but one event identity can join them.

At present, notice 502905 provides that identity but not the join. It names the event and affected components. It records the initial explanation. It does not publish the transition from investigation to recovery, even though its top-level state is now recovering. It does not publish the transition from recovery to resolution. It has no end time. Meanwhile, the linked components appear operational without an observable recovery note explaining when or why their state changed.

The missing object is a closure receipt

AFRINIC does not need to publish internal logs, infrastructure details or a forensic report for every website interruption. A compact closure receipt would be enough.

It should carry the stable notice ID, start time, affected component IDs and the last confirmed impact. It should identify the recovery observation: what service class was checked, when the check occurred, which acceptance condition passed and whether monitoring continued. It should then record the closure decision, decision time, responsible operational role, residual condition and final public message. The receipt should update the notice, page summary and history as one transition.

The critical field is not a prose promise that everything is fine. It is the derivation. If a present recovering notice may coexist with a green page, the page response should say why: for example, current_service_operational=true, open_incident_count=1, open_incident_phase=recovering, and page_state_rule=component-current-state. If policy says any present unplanned incident prevents an all-clear, the calculation should enforce that instead. Either rule is defensible when explicit. The current contradiction is not.

A monotonic event log would prevent silent regression. Updates should append rather than overwrite the history of state transitions. The system could reject ended_at=null when an incident is moved to a terminal state, and reject an all-clear projection when a notice classified as present has no declared exception. If an operator reopens an incident, that should be a new transition with a reason, not a disappearance of the earlier closure.

The same receipt should preserve correction history. Human status operations are prone to missed clicks, delayed updates and category errors. Treating correction as misconduct would discourage repair. A visible “administrative closure recorded on 11 September; service recovery observed earlier” is better than quietly editing the past. It separates the operational time from the publication time and allows users to understand the lag.

Why the inconsistency is operationally expensive

Status pages increasingly feed machines. A dependency monitor may consume the simple overview because the API documentation advertises it as the uncomplicated answer. An incident-management tool may subscribe to notice transitions. A human may read the history. If the overview is green while the notice never closes, those consumers retain different truths.

The first cost is alerting. A consumer that trusts only page state may stand down, while one that tracks present notices may keep an incident open indefinitely. The second is measurement. Mean time to recovery cannot be calculated from a null end time, even if the service recovered quickly. The third is governance. A later review cannot tell whether recovery was accepted, assumed from a component check or merely reflected by a manual colour change.

The fourth cost is habituation. If open notices routinely coexist with all-clear pages, users learn to ignore one of the surfaces. That choice may be harmless in this event and damaging in the next. Trust in status communication does not disappear because one field is stale; it weakens because readers stop knowing which field deserves priority.

This is especially material for a regional Internet registry. AFRINIC’s website is not the registry database, RPKI service or member portal, and this article does not conflate them. But the status domain is the common public place where AFRINIC represents multiple service classes. Its credibility depends on disciplined state distinctions precisely because the underlying services have different consequences.

What the evidence can support

The frozen public responses support a limited conclusion. On 11 September 2026, the status overview was operational and all-clear; notice 502905 was present and recovering; its end time was null; its only visible update remained the investigating message; and its two linked website components were operational. The public history showed the earlier June incident as the latest completed event.

Those facts do not establish present downtime, degradation, an SLC failure, a missed subscriber alert, member harm or concealment. They do not reveal the status system’s code or AFRINIC’s internal incident file. The component updated_at values are record timestamps, not proven probe times, and should not be used to invent a monitoring cadence.

The defensible finding is that the public account lacks a common closing transaction. AFRINIC may have restored the website promptly and recorded the event elsewhere. The status page still needs to say so in the object it asks users and machines to trust.

Green should describe the result of a closed chain, not obscure the link that remains open.

Sources