Summary

  • APNIC’s notice sets a six-hour Kubernetes upgrade window for 21 October; the public status page gives the matching UTC interval.
  • The linked iCalendar feed records the same event from 19 October 22:30 UTC, a day earlier. The schedule conflict does not establish an outage or actual impact.

One upgrade, two start dates

APNIC’s service announcement schedules a Kubernetes-cluster upgrade for Wednesday, 21 October 2026, from 08:30 to 14:30 UTC+10. It warns that node cycling may cause brief interruptions. The notice describes a six-hour work window; it does not say each named service will be unavailable for six hours.

The public Services Status page renders the same event from 20 October at 22:30 UTC to 21 October at 04:30 UTC. That is the same six-hour interval as the notice. The iCalendar feed differs: its event is titled “Kubernetes upgrade,” links in its description to the same 21 October notice, but records DTSTART;TZID=UTC:20261019T223000 and DTEND;TZID=UTC:20261020T043000.

Those iCalendar timestamps convert to 20 October, 08:30–14:30 UTC+10 in Brisbane—exactly one day before the notice and the status-page rendering. The feed labels its timestamps UTC, so the 24-hour gap is not explained by reading the time as Brisbane local time. The matching event title, six-hour duration and direct notice link show that the records refer to the same planned work.

For a team that imports the feed into its own change calendar, the difference is practical: the feed displays a different day from APNIC’s notice and status page. The evidence does not show which date APNIC expects operators to follow, whether anyone acted on the earlier entry, or whether any service will be interrupted. The announced work is still prospective in the records reviewed here.

Sources

The comparison uses APNIC’s service announcement, its public status page and its iCalendar feed.