Summary

  • The 08:38 UTC capture of APNIC’s WHOIS and RDAP JSON covers 27 October, 05:00–06:00 UTC; its MD5 sidecar matches the downloaded file. Hourly publication had resumed.
  • The October archive has no files for 92 hourly starts from 23 October 04:00 through 26 October 23:00 UTC. APNIC’s 16 October notice still has blank end-time and duration fields, with no interval-level repair list.

The feed is back. The missing hours did not walk in behind it.

At 08:38 UTC, APNIC’s current JSON covered 05:00–06:00 UTC on 27 October. Its MD5 sidecar matched the downloaded file. The October directory then contained reports through 04:00–05:00 UTC. Hourly publication had resumed.

The archive has a different story. Its last file before the gap covers 23 October, 03:00–04:00 UTC. The next file starts at midnight on 27 October. Between those intervals sit 92 hourly starts with no archive file. APNIC has restored the latest report; the calendar still has a four-day hole.

The arithmetic comes straight from APNIC’s filing rules. Its README says each report covers one half-open UTC hour and that a successful new report replaces the latest file while the previous one moves into the monthly archive. The filename ending 20261023-0300 covers 03:00–04:00. The next expected name begins at 04:00. The archive resumes at 20261027-0000. That is 92 hours without a file.

APNIC’s 16 October service notice starts the earlier incident at 10:00 UTC+10, or 00:00 UTC. It names “Whois and RDAP stats,” attributes the problem to log processing, says statistics from that point are incomplete, and says generation was disabled while staff worked on the issue. APNIC promised to republish affected files after the problem was fixed. The notice leaves its end time and duration blank.

The archive now contains one visible repair clue: the 23 October 03:00–04:00 file was rewritten on 27 October at 03:12 UTC. New reports follow it. The public record gives readers a new current hour and a rewritten older one, but no list of which intervals were rebuilt, which remain incomplete, or which will stay unavailable. The service-update index still lists the original notice without a closing entry.

That gap changes how a time series behaves. A missing hour can vanish from a chart, become an interpolated value or quietly turn into zero. Each choice changes averages and alerts. APNIC’s hourly reports contain query totals, query-type distributions and distinct source-IP counts by origin ASN. Their timestamps and checksums make individual files easy to verify. A per-hour completeness state and correction history would make the series easy to interpret as a whole.

A checksum can vouch for bytes. It cannot write the repair ledger.

APNIC already has the pieces for a tidy recovery record. Each corrected interval could list its UTC start and end, status, original publication time, correction time, current checksum and any superseded checksum. A compact manifest could mark each missing hour as republished, unavailable or withheld, then link to the relevant file. Researchers could keep the original record, identify the replacement and rerun calculations without reverse-engineering the directory.

The distinction is practical. The current checksum says the bytes downloaded match the file APNIC published. The filename says which hour the report covers. The service notice says the statistics became incomplete from 16 October 00:00 UTC onward. A correction manifest would connect those facts interval by interval.

The notice names the statistics generator and the statistics files. APNIC’s 27 October report shows publication has resumed. The next useful update is a list of affected hours, corrected-file checksums and a closeout for the October 16 notice. The clock is back on the wall; the archive still owes readers 92 lines.

Sources

APNIC service announcement, 16 October 2026; APNIC service-update index; APNIC WHOIS and RDAP statistics README; current statistics JSON; current MD5 sidecar; October hourly archive; 23 October 03:00 UTC archived file.