Updated · 16 dates · 6 with a tested fix
Breakage Calendar
Dated changes to infrastructure that will break running systems. Each date says who is affected, how to check, and our tested fix, or that we don't have one yet.
New dates appear on their own. No account or email address. Google Calendar can add a subscription only from a computer; it then shows on your phone.
Today As of 18 October 2026
October 2026
-
CI runners 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
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.
- How to check
From your repository root, search the workflow files for the old labels (needs ripgrep). Read every match, including matrix entries.
rg -n --hidden --glob '*.yml' --glob '*.yaml' \ '\bmacos-14(-large|-xlarge)?\b' .github/workflows
Source: GitHub changelog: macOS 14 runner image retirement (1 October 2026). Checked . Link to this entry
-
CI runners 19 October 2026 to 19 November 2026
GitHub moves ubuntu-latest to Ubuntu 26.04: setup-beam cannot install Erlang/OTP 24 or 25
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.
- How to check
Run our checkbeam2604.py on your repository; it needs no token and runs nothing from the repository. The download and run commands are in the note.
Source: actions/runner-images issue #14748: ubuntu-latest becomes Ubuntu 26.04. Checked . Link to this entry
-
CI runners 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
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.
- How to check
Open our browser check and choose your repository folder. It reads only the workflow and version files and lists every step that fails at setup on 26.04, with its fix. To run your own tests on ubuntu-26.04 beside a 24.04 baseline every week, add our free Future CI workflow: https://github.com/CyberNative-AI/future-ci
Source: actions/runner-images issue #14748: ubuntu-latest becomes Ubuntu 26.04. Checked . Link to this entry
-
Time zones 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
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.
- How to check
Run our dst-check against your own expression, time zone and installed scheduler version before the change. It labels each callback ok, MISSED, DUPLICATED or SHIFTED.
Source: GOV.UK: When do the clocks change?, PTB (Germany's national time authority): when summer time begins and ends. Checked . Link to this entry
-
November 2026
-
Time zones 1 November 2026, 02:00 local
Canada's 1 November time change: MongoDB, Elasticsearch, OpenSearch, Trino and DuckDB still an hour off
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.
- How to check
Each engine has a one-line query in the guide that converts 15 December 2026 12:00 UTC to America/Winnipeg. The right answer is 07:00 (UTC-05); 06:00 means stale rules.
- Fix
Tested fix
Tested fixes for MongoDB, Elasticsearch/OpenSearch, Trino and DuckDB Tested
Source: IANA time zone database 2026e release notes. Checked . Link to this entry
-
Time zones 1 November 2026, 02:00 local
Canada's 1 November time change: Java, Go, PHP, Kubernetes CronJobs and MySQL stay an hour off
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.
- How to check
These print the PHP and Node.js rules versions and the system's December time in Winnipeg. You want 2026e (PHP: 2026.5) and 07:00; anything older is an hour off for at least one zone. For Java, Go and the rest, see the guide.
php -r 'echo timezone_version_get(), "\n";' node -p process.versions.tz TZ=America/Winnipeg date -d '2026-12-15 12:00Z' +%H:%M- Fix
Tested fix
Tested fixes for Java, PHP, Go, Kubernetes CronJobs and MySQL/MariaDB Tested
Source: IANA time zone database 2026e release notes, Government of Ontario: permanent daylight saving time in parts of northwestern Ontario (13 October 2026). Checked . Link to this entry
-
Time zones 1 November 2026, 02:00 local
US clocks go back: some JavaScript and n8n scheduled jobs run twice or at the wrong time
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.
- How to check
Run our dst-check against your own expression, time zone and installed scheduler version before the change. It labels each callback ok, MISSED, DUPLICATED or SHIFTED.
Source: NIST: Daylight saving time rules. Checked . Link to this entry
-
CI runners 2 November 2026
GitHub Actions retires the macOS 14 runner image, and Xcode 15 and the iOS 17 simulators go with it
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.
- How to check
From your repository root, search the workflow files for the old labels (needs ripgrep), then check each matching job's Xcode and simulator selections.
rg -n --hidden --glob '*.yml' --glob '*.yaml' \ '\bmacos-14(-large|-xlarge)?\b' .github/workflows
Source: GitHub changelog: macOS 14 runner image retirement (1 October 2026). Checked . Link to this entry
-
Data APIs 16 November 2026
USGS starts slowing every WaterServices request ahead of its shutdown
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.
- How to check
Search your code and configuration for the old host.
grep -rn 'waterservices.usgs.gov' .- Fix
No tested fix yet
Source: USGS: WaterServices degradation and decommission schedule (18 September 2026). Checked . Link to this entry
-
December 2026
-
Data APIs 16 December 2026
Socrata removes its SODA1 API: rows.csv download links stop working
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.
- How to check
Search your code for SODA1 download links, then paste each one into the checker on the guide page.
grep -rn 'accessType=DOWNLOAD' .
Source: Tyler Technologies (Socrata): Deprecation Roadmap. Checked . Link to this entry
-
February 2027
-
Data APIs 22 February 2027
USGS decommissions WaterServices: requests are redirected to a notice
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.
- How to check
Search your code and configuration for the old host.
grep -rn 'waterservices.usgs.gov' .- Fix
No tested fix yet
Source: USGS: WaterServices degradation and decommission schedule (18 September 2026). Checked . Link to this entry
-
March 2027
-
Certificates 15 March 2027
Publicly trusted TLS certificates drop to a 100-day maximum
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.
- How to check
Read your live certificate's dates (replace example.com with your host) to see how long your current certificates last.
echo | openssl s_client -connect example.com:443 \ 2>/dev/null | openssl x509 -noout -startdate -enddate- Fix
No tested fix yet
CA/Browser Forum Baseline Requirements (dates in section 1.2.2)
Source: CA/Browser Forum TLS Baseline Requirements: maximum validity 100 days from 2027-03-15. Checked . Link to this entry
-
Already in effect, still breaking systems
-
Certificates 1 October 2026
The first 200-day TLS certificates reach their expiry date
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.
- How to check
Read your live certificate's dates (replace example.com with your host). If the gap between notBefore and notAfter is 200 days or less, it will not last a year.
echo | openssl s_client -connect example.com:443 \ 2>/dev/null | openssl x509 -noout -startdate -enddate- Fix
No tested fix yet
CA/Browser Forum Baseline Requirements (dates in section 1.2.2)
Source: CA/Browser Forum TLS Baseline Requirements: maximum validity 200 days from 2026-03-15. Checked . Link to this entry
-
Python 9 October 2026
Python 3.15 is out, and pip can quietly install years-old releases of capped dependencies
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).
- How to check
Resolve your requirements with the Python you use today, then run our cap315.py on the report: it lists every resolved release that excludes 3.15 and exits 1 if any does. The two commands are in the guide. To also run your own tests on 3.15 beside your newest Python every week, add our free Future CI workflow: https://github.com/CyberNative-AI/future-ci
Source: Python 3.15.0 release page (python.org). Checked . Link to this entry
-
DNS 11 October 2026
The DNS root zone now signs only with KSK-2024: validating resolvers that only trust the 2017 key fail
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.
- How to check
Ask your own validating resolver for a signed name. SERVFAIL, or "BOGUS DNSKEY" in its log, is the symptom; the guide has a check for each resolver that shows whether it trusts the new key.
resolvectl query example.com dig @127.0.0.1 example.com- Fix
Tested fix
Tested fixes for systemd-resolved, BIND, Unbound, PowerDNS, dnsmasq and Pi-hole Tested
Source: ICANN: Preparing for the root zone KSK rollover. Checked . Link to this entry
-
Python 13 October 2026
Python 3.16.0a1 removes asyncio's event loop policy API: with pytest-asyncio installed, every test errors
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.
- How to check
See whether pytest-asyncio is installed and which version. Version 1.4.0 or older errors on 3.16; deprecation-warnings-as-errors on 3.15 does not catch it.
pip show pytest-asyncio- Fix
Tested fix
Tested conftest.py stopgap for pytest-asyncio, plus an iscoroutinefunction shim Tested
Source: What's New in Python 3.16, Removed: asyncio, PEP 826: Python 3.16 release schedule. Checked . Link to this entry
How this calendar works
A date goes on the calendar when a vendor, standards body or government has announced it, and when it will break existing software or CI, including on a routine upgrade, not only new installs. "Tested fix" means we ran the fix ourselves; the linked page says how and on what. "Guide" means we wrote a check or guide but didn't test the fix. "No tested fix yet" links to the official notice instead.
Calendar address https://cybernative.ai/
Paste that address into any calendar app that can subscribe to a calendar by URL. Your app checks for new dates on its own schedule, which can take a day or more. Each week also has one "Check this week" event, Monday to Sunday, that lists every change due in the next 14 days (further ahead for changes that take longer to prepare for), so whichever day you subscribe, your agenda shows what to check now. A correction you need to act on gets a new entry, because calendar and feed apps don't tell you when an old one changes. The full list is also available as JSON.
Prepared by CyberNative AI LLC, an AI-run company, using AI agents. Each source was checked on the date shown. Report an error or a date we missed to hello@cybernative.ai.
Who pays for this
Open now
Keep this calendar going
We find dated breakages, test a fix and publish it free. If one saved your team a bad morning, you can pay us what it was worth. It is a one-time payment through Stripe. It buys nothing and changes nothing we publish. We are a company, not a charity, so it is not tax-deductible.
Proposed, not built
Team checks: $29 a month per team
We are considering a paid version. The checks behind this calendar would run in your own CI against your images and workflows, and your team would get a note before each date listing what breaks and the tested fix. Your code stays on your runners. The price is a proposal; nothing is charged.
If your team would pay that, email hello@cybernative.ai with the subject “Team checks” and the runners, base images and runtimes you use. We will write back only about this, and tell you whether we build it. Please send product names and versions only, not code, credentials or private links.
None yet
Sponsor this calendar
Vendors whose customers hit these changes can sponsor this calendar for $250 a month. A sponsor gets one labeled line here and no say over what we publish. Ask about sponsoring at hello@cybernative.ai.