Summary

  • APNIC’s Q2 2026 Activity Report puts Honeynet availability at 99.17%, against a goal of less than 5% downtime for “core Honeynet infrastructure.”
  • The same report says the infrastructure and sensor-software upgrade is complete, but gives no measurement window, component list, or calculation method for the score.

A percentage without a clock

99.17% looks like the kind of number a dashboard was born to display: precise, reassuring, and ready for a board slide. APNIC’s Executive Council minutes, adopted on 19 October, attach an Activity Report for Q2 2026 that gives exactly that score for Honeynet availability. Its target is to keep downtime below 5% for core Honeynet infrastructure. The report also says the infrastructure and sensor-software upgrade was completed.

The arithmetic is easy. If the target and result use the same period and denominator, less than 5% downtime means more than 95% availability. A score of 99.17% sits 4.17 percentage points above that implied floor; its complement is 0.83%. That is a strong-looking result. It is not yet a reproducible one.

The report does not name the interval’s start or end, say whether the measurement covers the whole quarter, list the components included in “core,” or show the numerator and denominator. It does not define a failed check, explain whether planned work counts as downtime, or say whether the figure is a time-weighted measure, a count of successful probes, or a blend. The upgrade is marked complete, but the report does not date it or say how its deployment window affects the score.

Those omissions matter because “Honeynet availability” can describe several different things. APNIC’s public security pages say the project draws on more than 400 honeypots worldwide and feeds suspicious-traffic information into tools including DASH. A reliable central platform, reachable sensors, fresh feeds, and a useful dashboard are related services. They are not interchangeable components of one percentage.

The Q2 report records security-information sharing sessions at Phoenix Summit, PKCERT Workshop, and PacNOG, and presentations at those events and CyberQuest Honiara. It also says planned Honeynet content was postponed to Q3 because more data was needed to draw conclusions. That is a sensible editorial threshold. It makes the missing denominator more conspicuous: APNIC is careful about what the threat data can prove, while the public service score arrives without enough detail to reproduce it.

This is a reporting gap, not evidence of an outage. APNIC reports no sensor failure, data loss, or member impact in this status block. The figure tells readers what the organisation reported, not which sensors were reachable or whether a member saw a delay in DASH. One number cannot carry all those jobs.

Put the service boundary on the page

APNIC could make the next report far more useful with a compact method note: the exact measurement dates; the systems counted as core; the probe cadence and failure threshold; the available and total checks or minutes; treatment of planned maintenance; and whether the score is weighted by time or component. A separate freshness measure for the Honeynet feed, plus a sensor-coverage count, would keep infrastructure uptime from impersonating intelligence quality.

That is not bureaucratic garnish. A security team deciding whether to rely on a feed needs to know whether a quiet dashboard means no relevant activity, stale data, or a service interruption. A member evaluating APNIC’s security tools needs to know what the availability promise covers. The Q2 score could be entirely accurate and still answer neither question.

Sources