Summary

  • AFRINIC’s notice 510608 ran for 17 hours, 22 minutes and 14 seconds from 1 to 2 October 2026, then moved to resolved.
  • The notice names no affected function or member group; a separate component record labels MyAFRINIC Portal operational, updated near the incident start.

Analysis

The event is specific enough to time and too broad to scope. AFRINIC Status logged an unplanned “Service Impact - Myafrinic Access Issue” at 12:07:29.099 UTC on 1 October and resolved it at 05:29:43.202 UTC on 2 October. The interval is 17 hours, 22 minutes and 14.103 seconds. The first update said a problem was affecting the MyAFRINIC portal while a technical team investigated. The second said only that the incident was resolved. The notice supplies no root cause, service symptoms or recovery check.

“Access” can cover several different failures. AFRINIC describes MyAFRINIC as a member service for managing contact information, resources, billing and support requests. Its member guidebook assigns different account functions to administrative, technical and billing contacts. Those distinctions matter: the status notice does not say whether login, account viewing, resource changes, invoice access or support requests were affected.

The structured component list adds a useful limit. It labels “MyAFRINIC Portal” operational; its updated_at is 12:07:29.123 UTC, about 24 milliseconds after the incident’s recorded start. A component state and an incident notice answer different questions. The API does not link the notice to a failed workflow or explain whether the operational label reflects a partial service, a separate monitor or a refreshed check. The record establishes neither a full portal outage nor an absence of member disruption.

For a registry, the evidenced issue sits at the member-administration layer. A portal notice alone does not demonstrate changes to WHOIS, routing, RPKI, resource allocations or billing records. AFRINIC published no member count, delayed request, missed payment or data change. The evidence is narrower: access to the portal was affected for a defined interval, and AFRINIC later marked the incident resolved.

A useful incident record would connect that interval to the functions members actually use: affected roles, visible symptoms, workaround, queue handling and the test that supported resolution. A member could then decide whether to retry an action or verify that a request reached the registry. The missing detail does not prove harm; it limits what members and observers can verify.

Sources