Summary

  • APNIC reported two separate 28-minute incidents affecting MyAPNIC on 15 and 17 September. The first followed a configuration change; the second was attributed to a database problem that also delayed ticketing email.
  • Equal duration and proximity do not prove a common cause. The missing public fact is narrower: whether APNIC compared the incidents’ dependency paths and found a link, ruled one out or left the question open.

Two outages can be individually explained and collectively unresolved.

APNIC’s 15 September service notice records a MyAPNIC Member Portal incident from 13:58 to 14:26, UTC+10. It says a configuration change to one MyAPNIC component had a broader-than-expected impact on other MyAPNIC functions. The stated follow-up is a fix intended to prevent similar changes from having the same effect.

The 17 September notice records another 28-minute interval, from 14:50 to 15:18, UTC+10. This time APNIC identifies a database problem. Emails to its ticketing system were delayed and some MyAPNIC functions were unavailable. The stated response is better database monitoring so similar problems can be fixed before they affect services.

Those are different public causal boundaries. The first is about the blast radius of a configuration change inside MyAPNIC. The second is about a database problem spanning ticketing email and some MyAPNIC functions. Nothing in either notice says the first event caused the second, that they shared a database or component, or that either produced data loss, security exposure, routing impact or resource-registration errors.

The timestamps create a legitimate review trigger, not a conclusion. The starts are 48 hours and 52 minutes apart, and both incidents lasted 28 minutes. Repeated duration may reflect the same detection interval, escalation cadence or recovery procedure. It may also be coincidence. The notices do not supply the evidence needed to choose among those possibilities.

What is absent is a cross-incident disposition. A reader cannot tell whether APNIC checked shared authentication, queues, data stores, configuration systems, deployment paths, monitoring blind spots or operational hand-offs. Nor can a reader tell whether such a comparison found no overlap, found a relevant dependency or remains unfinished.

That gap can be closed without exposing internal topology. A privacy-safe receipt would identify the two incident records, affected capability classes and evidence window. It would list the dependency domains checked, then mark the result as common factor found, common factor ruled out or still unknown. It could name a corrective-action owner, containment state and review date without publishing hostnames, credentials, member data, ticket contents, employee identities or exploit detail.

The distinction matters because the two notices point to different local remedies. Safer configuration-change containment will not necessarily improve database detection. Better database monitoring will not necessarily constrain the blast radius of a change. If the events were separate after review, saying so would strengthen both explanations. If they shared an operational surface, the combined action should be visible. If APNIC does not yet know, an explicit unknown is more informative than two isolated closure notes.

This is not a demand for a forensic dump or a theory of common cause. It is a request for one join between two already public records. Incident reporting establishes what happened inside each window. Correlation reporting establishes whether the organisation tested the boundary between them.

Sources