Summary

  • AFRINIC said on 19 February 2026 that sustained traffic had exceeded its connectivity capacity, slowing some online services and internal support work. A bandwidth upgrade had been approved and implementation was under way.
  • The notice did not report an outage. AFRINIC’s published commitment defines uptime through servers being switched on and connected, while treating query response and issue resolution as separate measures.
  • Approval, provider delivery, activation and accepted restoration are different states. None can substitute automatically for measured behaviour under representative traffic.
  • A privacy-safe capacity-to-service acceptance account can connect the change to per-service latency, errors and availability, and to separate first-response and resolution results, without exposing topology or member cases.

There is a large operational territory between a service that works normally and a service that has disappeared. Pages still load, but late. A request still enters a queue, but the people answering it work through slower systems. Monitoring still sees a connected host, even as the interval between a user’s action and a useful result grows.

That is the territory AFRINIC described in its 19 February 2026 notice. It said sustained network traffic over the preceding few months had exceeded the connectivity capacity of its Mauritius data centre. Some online services might respond more slowly than usual. Internal support efficiency was affected, so replies to member queries and service requests might take longer than normal standards. A bandwidth upgrade had been approved and implementation was under way.

The notice is unusually useful because it does not force the condition into the language of an outage. It identifies a constraint, a service effect and a proposed technical response. It also states the intended outcome: significantly more capacity and restoration of normal service performance.

What it does not provide is the later join. The public record checked for this article does not say which services formed the acceptance set, what their performance looked like before the change, what capacity was approved, when the new path became active, how long it was observed or which measurements established that normal performance had returned. That is not proof that AFRINIC lacks those records. It is the boundary of what the notice and the retrieved public status history allow a reader to reconstruct.

The service stayed on; the experience changed

AFRINIC’s Service Level Commitment makes the evidence problem visible. Its uptime commitment is 99.8 per cent for each service and for the network. The document defines uptime as the percentage of time servers are physically switched on and have an Internet connection to running services. Scheduled maintenance, third-party unavailability, end-user connectivity problems and force majeure are excluded from the calculation.

That is a meaningful continuity test. Power and connectivity are prerequisites for an online registry service. But they are not a speed test. A server may be on and reachable while congestion increases latency, pages time out intermittently, or a support team waits longer for an internal operation to complete. The February notice itself supplies the distinction: its chosen symptom was slower response, not loss of power or connection.

The same commitment separates two further clocks. It promises an effective response to queries within two working days. It defines response time as how quickly AFRINIC responds to an issue, and resolution time as the period from logging until the issue is fully resolved. A first reply can arrive while the underlying matter remains open. A resolved case can require many exchanges after the first reply. Neither clock proves how quickly the online service used to handle the case was responding.

Published measure What it can establish What it cannot establish alone
Service or network uptime Whether the stated power-and-connectivity condition held, subject to exclusions That transactions were fast enough or that capacity pressure ended
Query response time How quickly AFRINIC first responded to an issue That the issue was fully resolved or the supporting service recovered
Resolution time How long a logged issue took to reach full resolution That the first response was timely or that every online service performed normally

The three measures can move in different directions. During congestion, uptime might remain high while transaction latency rises. A support team may still acknowledge a request within two working days while resolution takes longer. After a capacity increase, service latency may improve immediately even though an existing queue takes time to clear. Reporting one result as a proxy for all three would erase precisely the state that the notice made visible.

A change is not one event

The phrase “implementation is underway” belongs to a change process, not its endpoint. An approval authorises a target. A provider handoff establishes an external dependency. Installation or configuration makes the new capacity technically available. Activation changes the running path. Observation tests what happens under load. Acceptance decides whether the result satisfies the intended service outcome. A rollback or correction may follow if it does not.

These distinctions do not imply that the work was mishandled. They are normal features of infrastructure change. A link can be active before peak traffic returns. A synthetic probe can pass while a member-facing transaction remains slow. One service can improve while another continues to depend on a different bottleneck. A larger nominal capacity can also be delivered correctly while an unrelated application problem keeps a particular page slow. The purpose of an acceptance record is to preserve these possibilities rather than compress them into success or failure by announcement.

The February notice gives no numbers, and none should be invented. It does not identify the prior link size, the measured traffic peak, a latency target, a provider, an installation date or an acceptance threshold. Even “significantly increase” is a statement about the expected change, not a reported measurement. The proper question is therefore not whether an undisclosed target was met. It is what evidence object would make the intended transition reproducible without disclosing sensitive network design.

Join capacity to the services it was meant to restore

A compact acceptance account can remain much thinner than a public engineering report. AFRINIC need not publish a topology, commercial price, provider configuration or member ticket. It can name service classes, use performance bands rather than raw internal values and keep detailed evidence behind protected references. What must survive is the relationship between the reason for the change and the conclusion drawn after it.

Acceptance element Why it belongs in the record
Notice and change identity Prevents a later capacity project from being mistaken for the February response
Affected-service classes and observation window Defines what restoration was meant to cover and when the constraint was observed
Privacy-safe baseline and approved target Keeps the starting condition and authorised objective distinct
Provider delivery and activation time Separates approval from the moment the running path changed
Representative load and acceptance window Prevents a quiet instant from standing for the conditions that caused congestion
Per-service latency, error and availability result Shows whether reachable services returned to an accepted operating range
First-response and resolution result Keeps support performance connected to, but not confused with, service performance
Exclusions, exceptions and dependency state Makes omitted observations and third-party boundaries visible
Authority, outcome and correction history Attributes accepted, partly accepted, still measuring or rolled back without erasing later change

This record is not a demand for a new service-level promise. It is an account of whether a specific intervention achieved the outcome already named in the notice. AFRINIC could preserve exact measurements internally and publish narrower conclusions: which service classes were tested, the window used, whether each returned to an approved band and whether support response and resolution had recovered separately.

The difference between a service class and a product name is useful here. Public reporting might group member portal operations, directory queries and internal case handling without exposing hosts, links or user identities. If a group remained outside its band because of an unrelated dependency, that exception could be stated without implying that the bandwidth purchase was defective. Partial acceptance is more informative than an artificial choice between triumph and failure.

A status page can carry closure, but it does not create it

AFRINIC’s status system already has vocabulary for state progression. A later, unrelated authoritative-DNS degradation notice moved through an investigating state, later updates and an explicit resolved state in April. That incident must not be attached to the February capacity condition. Its relevance is limited to design: the public surface can represent an incident as something that changes over time and eventually receives a closure state.

The retrieved status history exposed archive entries for January, April and June 2026, but not a February entry in the response checked for this article. That does not prove that a February incident record never existed, that no internal change record was kept or that the upgrade was not completed. A public archive view is not an inventory of every private operational record.

Nor would adding the word Resolved by itself answer the performance question. A closure label needs a basis. For a capacity event, that basis is not necessarily the same as for a DNS incident. It should identify activation, the representative window and the relevant service measures. The status page is the route through which a bounded result can become public; the acceptance account is what makes the result intelligible.

What remains unknown

The sources do not establish the date on which the bandwidth upgrade became active. They do not say whether the target was reached, whether a provider dependency delayed it, whether the affected services returned to normal together or whether a staged acceptance process was used. They do not report present degradation.

They also do not establish an SLC breach. A notice that replies may take longer than normal standards is not a case log showing that a particular response exceeded two working days. Slower online service is not equivalent to failing the SLC’s literal uptime definition. The absence of a public acceptance result cannot be converted into proof of an operational failure.

The bounded finding is still consequential. AFRINIC publicly named a service-performance problem and a capacity intervention intended to restore normal performance. Its standing commitment separately names uptime, response and resolution. A later public result should therefore preserve those measures rather than allowing one to substitute for the others.

The link may have been upgraded. The services may have recovered. The checked record cannot close that sequence. Uptime can show that infrastructure remained connected; only a capacity-to-service acceptance result can show what the added bandwidth did.

Sources