<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <title>CyberNative Breakage Calendar</title>
  <subtitle>Dated infrastructure changes that will break running systems: who is affected, how to check, and a tested fix where we have one.</subtitle>
  <id>https://cybernative.ai/breakage-calendar/feed.xml</id>
  <link rel="self" type="application/atom+xml" href="https://cybernative.ai/breakage-calendar/feed.xml"/>
  <link rel="alternate" type="text/html" href="https://cybernative.ai/breakage-calendar/"/>
  <updated>2026-10-18T00:00:00Z</updated>
  <author><name>CyberNative AI LLC</name><uri>https://cybernative.ai/</uri></author>
  <icon>https://cybernative.ai/assets/brand/favicon.svg</icon>
  <entry>
    <title>1 October 2026: The first 200-day TLS certificates reach their expiry date</title>
    <link rel="alternate" type="text/html" href="https://cybernative.ai/breakage-calendar/#2026-10-01-tls-200-day-certificates-first-expiries"/>
    <id>https://cybernative.ai/breakage-calendar/#2026-10-01-tls-200-day-certificates-first-expiries</id>
    <published>2026-10-18T00:00:00Z</published>
    <updated>2026-10-18T00:00:00Z</updated>
    <category term="Certificates"/>
    <summary>Since 15 March 2026, publicly trusted TLS certificates can be valid for at most 200 days, down from 398. A certificate issued on 15 March with the full 200 days expired on 1 October 2026, so certificates now need renewing at least twice a year. Who is affected: Anyone who renews certificates by hand or plans renewals around a once-a-year reminder. Automated renewal now has to succeed at least twice a year. No tested fix yet.</summary>
  </entry>
  <entry>
    <title>9 October 2026: Python 3.15 is out, and pip can quietly install years-old releases of capped dependencies</title>
    <link rel="alternate" type="text/html" href="https://cybernative.ai/breakage-calendar/#2026-10-09-python-3-15-pip-installs-old-releases"/>
    <id>https://cybernative.ai/breakage-calendar/#2026-10-09-python-3-15-pip-installs-old-releases</id>
    <published>2026-10-18T00:00:00Z</published>
    <updated>2026-10-18T00:00:00Z</updated>
    <category term="Python"/>
    <summary>Python 3.15.0 was released on 9 October 2026. Some popular packages declare a requires_python that stops below 3.15; on 3.15, pip skips those releases and installs an older one without a warning, while uv ignores the cap and installs the latest. Who is affected: Projects moving to Python 3.15 that depend on packages with a requires_python cap below 3.15. In our wheels-only test with pip 26.2.1 on 11 October, that included aiogram, great-expectations, youtube-transcript-api, voyageai and modal (old releases installed), and dagster, prefect, google-ads, mistral-common and snowflake (install fails without naming the cap). Guide: Check script and what to do: put a floor on direct dependencies so pip fails loudly.</summary>
  </entry>
  <entry>
    <title>11 October 2026: The DNS root zone now signs only with KSK-2024: validating resolvers that only trust the 2017 key fail</title>
    <link rel="alternate" type="text/html" href="https://cybernative.ai/breakage-calendar/#2026-10-11-root-ksk-2024-dnssec-rollover"/>
    <id>https://cybernative.ai/breakage-calendar/#2026-10-11-root-ksk-2024-dnssec-rollover</id>
    <published>2026-10-18T00:00:00Z</published>
    <updated>2026-10-18T00:00:00Z</updated>
    <category term="DNS"/>
    <summary>On 11 October 2026 the DNS root zone began using only its new key-signing key, KSK-2024 (key tag 38696). A DNSSEC-validating resolver that does not trust it fails to resolve names. Who is affected: Validating resolvers whose built-in or configured trust anchor has only the 2017 key, for example systemd-resolved on Ubuntu 22.04 and 24.04, fresh BIND installs on Ubuntu 20.04 and Debian 11, and some routers, Pi-hole setups and DNS server images. Tested fix: Tested fixes for systemd-resolved, BIND, Unbound, PowerDNS, dnsmasq and Pi-hole.</summary>
  </entry>
  <entry>
    <title>13 October 2026: Python 3.16.0a1 removes asyncio's event loop policy API: with pytest-asyncio installed, every test errors</title>
    <link rel="alternate" type="text/html" href="https://cybernative.ai/breakage-calendar/#2026-10-13-python-3-16-asyncio-policy-removal"/>
    <id>https://cybernative.ai/breakage-calendar/#2026-10-13-python-3-16-asyncio-policy-removal</id>
    <published>2026-10-18T00:00:00Z</published>
    <updated>2026-10-18T00:00:00Z</updated>
    <category term="Python"/>
    <summary>Python 3.16.0a1, released 13 October 2026, removes asyncio's event loop policy system and asyncio.iscoroutinefunction(), both deprecated since 3.14. Who is affected: Projects that add Python 3.16 to CI. With pytest-asyncio 1.4.0 (the current release) installed, every test errors at setup, including plain synchronous tests. Code that calls get_event_loop_policy() or set_event_loop_policy() fails too. Tested fix: Tested conftest.py stopgap for pytest-asyncio, plus an iscoroutinefunction shim.</summary>
  </entry>
  <entry>
    <title>16–30 October 2026, 14:00 to 24:00 UTC on each brownout day: GitHub Actions: jobs on macOS 14 runners fail during scheduled brownouts</title>
    <link rel="alternate" type="text/html" href="https://cybernative.ai/breakage-calendar/#2026-10-16-github-macos-14-brownouts"/>
    <id>https://cybernative.ai/breakage-calendar/#2026-10-16-github-macos-14-brownouts</id>
    <published>2026-10-18T00:00:00Z</published>
    <updated>2026-10-18T00:00:00Z</updated>
    <category term="CI runners"/>
    <summary>GitHub makes jobs on the macOS 14 image fail for ten hours on six days before it retires the image: 14:00 UTC to midnight UTC on 16, 19, 23, 26, 29 and 30 October 2026. Who is affected: Workflows that use the labels macos-14, macos-14-large or macos-14-xlarge. Guide: Find the labels, pick the replacement by architecture, check Xcode and simulators.</summary>
  </entry>
  <entry>
    <title>19 October 2026 to 19 November 2026: GitHub moves ubuntu-latest to Ubuntu 26.04: setup-beam cannot install Erlang/OTP 24 or 25</title>
    <link rel="alternate" type="text/html" href="https://cybernative.ai/breakage-calendar/#2026-10-19-ubuntu-latest-26-04-erlang-setup-beam"/>
    <id>https://cybernative.ai/breakage-calendar/#2026-10-19-ubuntu-latest-26-04-erlang-setup-beam</id>
    <published>2026-10-18T00:00:00Z</published>
    <updated>2026-10-18T00:00:00Z</updated>
    <category term="CI runners"/>
    <summary>As ubuntu-latest moves to Ubuntu 26.04 (19 October to 19 November 2026), erlef/setup-beam installs Erlang/OTP builds made for 26.04, and that build list starts at OTP 26.0. Who is affected: Elixir and Erlang jobs on ubuntu-latest that ask for OTP 24 or 25, and any job pinned to setup-beam v1.24.0 or earlier, which does not recognise the 26.04 image whatever OTP version it asks for. Of 224 popular Hex packages' repositories that run setup-beam on ubuntu-latest, 89 had a job that fails this way. Guide: Checker and fixes per entry: keep old OTP on ubuntu-24.04, raise to OTP 26+, or update setup-beam.</summary>
  </entry>
  <entry>
    <title>19 October 2026 to 19 November 2026: GitHub moves ubuntu-latest to Ubuntu 26.04: setup-python and setup-ruby jobs fail for versions with no 26.04 build</title>
    <link rel="alternate" type="text/html" href="https://cybernative.ai/breakage-calendar/#2026-10-19-ubuntu-latest-26-04-python-ruby-setup"/>
    <id>https://cybernative.ai/breakage-calendar/#2026-10-19-ubuntu-latest-26-04-python-ruby-setup</id>
    <published>2026-10-18T00:00:00Z</published>
    <updated>2026-10-18T00:00:00Z</updated>
    <category term="CI runners"/>
    <summary>GitHub rolls the ubuntu-latest label from Ubuntu 24.04 to 26.04 over several weeks, starting 19 October and finishing by 19 November 2026. actions/setup-python and ruby/setup-ruby download a build made for the exact Ubuntu version, and far fewer builds exist for 26.04. Who is affected: Jobs on ubuntu-latest that ask for a Python or Ruby version with no 26.04 build: an old version such as Python 3.8 or 3.9, or an exact patch version, including pins in .python-version or .ruby-version. In a sample of 548 active public repositories, 122 had at least one such job. Tested fix: Browser check and fixes per entry; tested route for Python 3.8 and 3.9 on 26.04 (none yet for Ruby before 3.2).</summary>
  </entry>
  <entry>
    <title>25 October 2026, 01:00 UTC: UK and EU clocks go back: some JavaScript and n8n scheduled jobs run twice or at the wrong time</title>
    <link rel="alternate" type="text/html" href="https://cybernative.ai/breakage-calendar/#2026-10-25-europe-clocks-go-back-schedulers"/>
    <id>https://cybernative.ai/breakage-calendar/#2026-10-25-europe-clocks-go-back-schedulers</id>
    <published>2026-10-18T00:00:00Z</published>
    <updated>2026-10-18T00:00:00Z</updated>
    <category term="Time zones"/>
    <summary>The UK and the EU end summer time on 25 October 2026, so one local hour happens twice: 01:00 to 01:59 in London, 02:00 to 02:59 in Berlin. Who is affected: In our controlled-clock tests for London, cron 4.4.0 and node-schedule 2.1.1 ran half-hourly jobs twice in the repeated hour, and a daily cron job set just after it also fired once early. An n8n 2.40.7 daily 03:00 Schedule Trigger in Europe/Berlin fired twice, the extra run one hour early. Other versions and schedulers were not tested. Guide: Measured results per library and a check for your schedule (no tested fix).</summary>
  </entry>
  <entry>
    <title>1 November 2026, 02:00 local: Canada's 1 November time change: MongoDB, Elasticsearch, OpenSearch, Trino and DuckDB still an hour off</title>
    <link rel="alternate" type="text/html" href="https://cybernative.ai/breakage-calendar/#2026-11-01-canada-time-zone-change-databases"/>
    <id>https://cybernative.ai/breakage-calendar/#2026-11-01-canada-time-zone-change-databases</id>
    <published>2026-10-18T00:00:00Z</published>
    <updated>2026-10-18T00:00:00Z</updated>
    <category term="Time zones"/>
    <summary>Alberta, the Northwest Territories, Manitoba and British Columbia stop falling back on 1 November 2026. These data platforms carry their own copy of the time-zone rules, separate from the operating system's. Who is affected: Self-managed MongoDB, Elasticsearch, OpenSearch, Trino and DuckDB that report or bucket times in Canadian local time, or in Moroccan time, which old rules have had wrong since 20 September. Their newest releases were still wrong on 14 October. Tested fix: Tested fixes for MongoDB, Elasticsearch/OpenSearch, Trino and DuckDB.</summary>
  </entry>
  <entry>
    <title>1 November 2026, 02:00 local: Canada's 1 November time change: Java, Go, PHP, Kubernetes CronJobs and MySQL stay an hour off</title>
    <link rel="alternate" type="text/html" href="https://cybernative.ai/breakage-calendar/#2026-11-01-canada-time-zone-change-runtimes"/>
    <id>https://cybernative.ai/breakage-calendar/#2026-11-01-canada-time-zone-change-runtimes</id>
    <published>2026-10-18T00:00:00Z</published>
    <updated>2026-10-18T00:00:00Z</updated>
    <category term="Time zones"/>
    <summary>On 1 November 2026 Alberta, the Northwest Territories, Manitoba and British Columbia stop falling back. Rules older than IANA release 2026e show Calgary, Edmonton, Inuvik and Winnipeg an hour behind; rules older than April 2026 also get Vancouver wrong. Ontario has announced, but not yet published, the same for northwestern Ontario west of the 90th meridian, including Kenora; 2026e already includes it, so the same fixes cover it. Who is affected: Software that carries its own copy of the time-zone rules: every current Eclipse Temurin LTS Java (2026b; Temurin's October update is due 20 October), Go's built-in copy, PHP 8.2 and 8.3, Rust chrono-tz, Kubernetes CronJobs with timeZone (controller images on 2026b), and MySQL and MariaDB named time zones loaded before the change. Debian and Ubuntu packages were still on 2026c on 13 October. Tested fix: Tested fixes for Java, PHP, Go, Kubernetes CronJobs and MySQL/MariaDB.</summary>
  </entry>
  <entry>
    <title>1 November 2026, 02:00 local: US clocks go back: some JavaScript and n8n scheduled jobs run twice or at the wrong time</title>
    <link rel="alternate" type="text/html" href="https://cybernative.ai/breakage-calendar/#2026-11-01-us-clocks-go-back-schedulers"/>
    <id>https://cybernative.ai/breakage-calendar/#2026-11-01-us-clocks-go-back-schedulers</id>
    <published>2026-10-18T00:00:00Z</published>
    <updated>2026-10-18T00:00:00Z</updated>
    <category term="Time zones"/>
    <summary>Daylight saving time ends in most of the US at 02:00 local time on 1 November 2026, so 01:00 to 01:59 happens twice. Who is affected: In our controlled-clock tests, cron 4.4.0 and node-schedule 2.1.1 ran half-hourly jobs twice in the repeated hour, node-cron 4.6.0 picked different occurrences in New York and London, and an n8n 2.40.7 daily 02:30 Schedule Trigger in America/New_York fired twice, the extra run at 01:30. Other versions and schedulers were not tested. Guide: Measured results per library and a check for your schedule (no tested fix).</summary>
  </entry>
  <entry>
    <title>2 November 2026: GitHub Actions retires the macOS 14 runner image, and Xcode 15 and the iOS 17 simulators go with it</title>
    <link rel="alternate" type="text/html" href="https://cybernative.ai/breakage-calendar/#2026-11-02-github-macos-14-runner-retirement"/>
    <id>https://cybernative.ai/breakage-calendar/#2026-11-02-github-macos-14-runner-retirement</id>
    <published>2026-10-18T00:00:00Z</published>
    <updated>2026-10-18T00:00:00Z</updated>
    <category term="CI runners"/>
    <summary>GitHub retires the macOS 14 runner image on 2 November 2026. Xcode 15, the iOS 17, 18.1 and 18.2 simulator runtimes and the iPhone 15 simulator devices are installed only on the macOS 14 images. Who is affected: Workflows that use macos-14, macos-14-large or macos-14-xlarge, and jobs that select Xcode 15, an iOS 17, 18.1 or 18.2 simulator or an iPhone 15 simulator, which no remaining image has. Guide: Replacement by architecture, and which Xcode and simulators each image has.</summary>
  </entry>
  <entry>
    <title>16 November 2026: USGS starts slowing every WaterServices request ahead of its shutdown</title>
    <link rel="alternate" type="text/html" href="https://cybernative.ai/breakage-calendar/#2026-11-16-usgs-waterservices-slowdown"/>
    <id>https://cybernative.ai/breakage-calendar/#2026-11-16-usgs-waterservices-slowdown</id>
    <published>2026-10-18T00:00:00Z</published>
    <updated>2026-10-18T00:00:00Z</updated>
    <category term="Data APIs"/>
    <summary>From 16 November 2026, USGS adds a 2-second delay to every request to waterservices.usgs.gov. The delay rises to 10 seconds on 11 January, 30 seconds on 25 January and 60 seconds on 1 February 2027. Requests are also redirected instead of answered for about 24 hours on 27 January and about 48 hours on 15 February. Who is affected: Scripts, dashboards and pipelines that call waterservices.usgs.gov, especially those making many requests or running under a timeout. No tested fix yet.</summary>
  </entry>
  <entry>
    <title>16 December 2026: Socrata removes its SODA1 API: rows.csv download links stop working</title>
    <link rel="alternate" type="text/html" href="https://cybernative.ai/breakage-calendar/#2026-12-16-socrata-soda1-removal"/>
    <id>https://cybernative.ai/breakage-calendar/#2026-12-16-socrata-soda1-removal</id>
    <published>2026-10-18T00:00:00Z</published>
    <updated>2026-10-18T00:00:00Z</updated>
    <category term="Data APIs"/>
    <summary>Tyler Technologies removes Socrata's SODA1 API on 16 December 2026. Links of the form /api/views/{dataset-id}/rows.csv?accessType=DOWNLOAD stop working; the documented replacement, export.csv, keeps column names but can turn numbers into formatted text. Who is affected: Scripts, notebooks and dashboards that download open-data portals' rows.csv files. In 65 of 120 popular datasets we sampled, export.csv turned at least one plain-number column into formatted text. Tested fix: Replacement URL plus pandas and R code that keeps the old column names and numbers.</summary>
  </entry>
  <entry>
    <title>22 February 2027: USGS decommissions WaterServices: requests are redirected to a notice</title>
    <link rel="alternate" type="text/html" href="https://cybernative.ai/breakage-calendar/#2027-02-22-usgs-waterservices-decommissioned"/>
    <id>https://cybernative.ai/breakage-calendar/#2027-02-22-usgs-waterservices-decommissioned</id>
    <published>2026-10-18T00:00:00Z</published>
    <updated>2026-10-18T00:00:00Z</updated>
    <category term="Data APIs"/>
    <summary>USGS decommissions WaterServices on 22 February 2027. From that day, every request to waterservices.usgs.gov is redirected to a decommissioning blog post instead of returning data. Who is affected: Anything still calling waterservices.usgs.gov instead of the new Water Data APIs. No tested fix yet.</summary>
  </entry>
  <entry>
    <title>15 March 2027: Publicly trusted TLS certificates drop to a 100-day maximum</title>
    <link rel="alternate" type="text/html" href="https://cybernative.ai/breakage-calendar/#2027-03-15-tls-100-day-certificates"/>
    <id>https://cybernative.ai/breakage-calendar/#2027-03-15-tls-100-day-certificates</id>
    <published>2026-10-18T00:00:00Z</published>
    <updated>2026-10-18T00:00:00Z</updated>
    <category term="Certificates"/>
    <summary>From 15 March 2027, publicly trusted TLS certificates can be valid for at most 100 days, and domain validation can be reused for at most 100 days, down from 200 for both. Who is affected: Anyone who renews certificates by hand or on a fixed schedule built around 200-day certificates. Renewal will be needed at least every 100 days, about four times a year. No tested fix yet.</summary>
  </entry>
</feed>
