{ "title": "CyberNative Breakage Calendar", "page": "https://cybernative.ai/breakage-calendar/", "updated": "2026-10-18", "entries": [ { "id": "2026-10-01-tls-200-day-certificates-first-expiries", "added": "2026-10-18", "short": "First 200-day TLS certificates expire", "date": "2026-10-01", "dateEnd": null, "datePrecision": "day", "time": null, "title": "The first 200-day TLS certificates reach their expiry date", "area": "Certificates", "what": "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.", "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.", "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.", "checkCode": "echo | openssl s_client -connect example.com:443 \\\n 2>/dev/null | openssl x509 -noout -startdate -enddate", "fix": { "kind": "none", "href": "https://cabforum.org/working-groups/server/baseline-requirements/requirements/", "label": "CA/Browser Forum Baseline Requirements (dates in section 1.2.2)", "testedAt": null }, "sources": [ { "label": "CA/Browser Forum TLS Baseline Requirements: maximum validity 200 days from 2026-03-15", "href": "https://cabforum.org/working-groups/server/baseline-requirements/requirements/", "checkedAt": "2026-10-14" } ] }, { "id": "2026-10-09-python-3-15-pip-installs-old-releases", "added": "2026-10-18", "short": "Python 3.15: pip may install years-old releases", "date": "2026-10-09", "dateEnd": null, "datePrecision": "day", "time": null, "title": "Python 3.15 is out, and pip can quietly install years-old releases of capped dependencies", "area": "Python", "what": "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.", "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).", "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", "checkCode": null, "fix": { "kind": "guide", "href": "https://github.com/CyberNative-AI/.github/tree/main/notes/python315-install-fallback", "label": "Check script and what to do: put a floor on direct dependencies so pip fails loudly", "testedAt": null }, "sources": [ { "label": "Python 3.15.0 release page (python.org)", "href": "https://www.python.org/downloads/release/python-3150/", "checkedAt": "2026-10-14" } ] }, { "id": "2026-10-11-root-ksk-2024-dnssec-rollover", "added": "2026-10-18", "short": "DNS root key roll: old trust anchors fail", "date": "2026-10-11", "dateEnd": null, "datePrecision": "day", "time": null, "title": "The DNS root zone now signs only with KSK-2024: validating resolvers that only trust the 2017 key fail", "area": "DNS", "what": "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.", "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.", "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.", "checkCode": "resolvectl query example.com\ndig @127.0.0.1 example.com", "fix": { "kind": "tested", "href": "/guides/root-ksk-2024-dnssec-fixes/", "label": "Tested fixes for systemd-resolved, BIND, Unbound, PowerDNS, dnsmasq and Pi-hole", "testedAt": "2026-10-12" }, "sources": [ { "label": "ICANN: Preparing for the root zone KSK rollover", "href": "https://www.icann.org/en/blogs/details/preparing-for-the-root-zone-ksk-rollover-what-you-need-to-know-27-07-2026-en", "checkedAt": "2026-10-14" } ] }, { "id": "2026-10-13-python-3-16-asyncio-policy-removal", "added": "2026-10-18", "short": "Python 3.16 alpha breaks pytest-asyncio", "date": "2026-10-13", "dateEnd": null, "datePrecision": "day", "time": null, "title": "Python 3.16.0a1 removes asyncio's event loop policy API: with pytest-asyncio installed, every test errors", "area": "Python", "what": "Python 3.16.0a1, released 13 October 2026, removes asyncio's event loop policy system and asyncio.iscoroutinefunction(), both deprecated since 3.14.", "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.", "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.", "checkCode": "pip show pytest-asyncio", "fix": { "kind": "tested", "href": "https://github.com/CyberNative-AI/.github/tree/main/notes/python-316-asyncio-removals", "label": "Tested conftest.py stopgap for pytest-asyncio, plus an iscoroutinefunction shim", "testedAt": "2026-10-14" }, "sources": [ { "label": "What's New in Python 3.16, Removed: asyncio", "href": "https://docs.python.org/3.16/whatsnew/3.16.html", "checkedAt": "2026-10-14" }, { "label": "PEP 826: Python 3.16 release schedule", "href": "https://peps.python.org/pep-0826/", "checkedAt": "2026-10-14" } ] }, { "id": "2026-10-16-github-macos-14-brownouts", "added": "2026-10-18", "short": "macOS 14 brownout: jobs fail 14:00–24:00 UTC", "date": "2026-10-16", "dateEnd": "2026-10-30", "datePrecision": "window", "time": "14:00 to 24:00 UTC on each brownout day", "title": "GitHub Actions: jobs on macOS 14 runners fail during scheduled brownouts", "area": "CI runners", "what": "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.", "affected": "Workflows that use the labels macos-14, macos-14-large or macos-14-xlarge.", "check": "From your repository root, search the workflow files for the old labels (needs ripgrep). Read every match, including matrix entries.", "checkCode": "rg -n --hidden --glob '*.yml' --glob '*.yaml' \\\n '\\bmacos-14(-large|-xlarge)?\\b' .github/workflows", "fix": { "kind": "guide", "href": "https://github.com/CyberNative-AI/.github/tree/main/notes/macos14-brownout", "label": "Find the labels, pick the replacement by architecture, check Xcode and simulators", "testedAt": null }, "sources": [ { "label": "GitHub changelog: macOS 14 runner image retirement (1 October 2026)", "href": "https://github.blog/changelog/2026-10-01-github-actions-macos-14-runner-image-retirement/", "checkedAt": "2026-10-14" } ], "days": [ "2026-10-16", "2026-10-19", "2026-10-23", "2026-10-26", "2026-10-29", "2026-10-30" ] }, { "id": "2026-10-19-ubuntu-latest-26-04-python-ruby-setup", "added": "2026-10-18", "short": "ubuntu-latest → 26.04: Python/Ruby setup fails", "date": "2026-10-19", "dateEnd": "2026-11-19", "datePrecision": "window", "time": null, "title": "GitHub moves ubuntu-latest to Ubuntu 26.04: setup-python and setup-ruby jobs fail for versions with no 26.04 build", "area": "CI runners", "what": "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.", "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.", "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", "checkCode": null, "fix": { "kind": "tested", "href": "/tools/ubuntu-2604-check/", "label": "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)", "testedAt": "2026-10-12" }, "sources": [ { "label": "actions/runner-images issue #14748: ubuntu-latest becomes Ubuntu 26.04", "href": "https://github.com/actions/runner-images/issues/14748", "checkedAt": "2026-10-14" } ] }, { "id": "2026-10-19-ubuntu-latest-26-04-erlang-setup-beam", "added": "2026-10-18", "short": "ubuntu-latest → 26.04: Erlang OTP 24/25 fail", "date": "2026-10-19", "dateEnd": "2026-11-19", "datePrecision": "window", "time": null, "title": "GitHub moves ubuntu-latest to Ubuntu 26.04: setup-beam cannot install Erlang/OTP 24 or 25", "area": "CI runners", "what": "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.", "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.", "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.", "checkCode": null, "fix": { "kind": "guide", "href": "https://github.com/CyberNative-AI/.github/tree/main/notes/ubuntu-2604-setup-beam", "label": "Checker and fixes per entry: keep old OTP on ubuntu-24.04, raise to OTP 26+, or update setup-beam", "testedAt": null }, "sources": [ { "label": "actions/runner-images issue #14748: ubuntu-latest becomes Ubuntu 26.04", "href": "https://github.com/actions/runner-images/issues/14748", "checkedAt": "2026-10-14" } ] }, { "id": "2026-10-25-europe-clocks-go-back-schedulers", "added": "2026-10-18", "short": "UK/EU clocks go back: some jobs run twice", "date": "2026-10-25", "dateEnd": null, "datePrecision": "day", "time": "01:00 UTC", "title": "UK and EU clocks go back: some JavaScript and n8n scheduled jobs run twice or at the wrong time", "area": "Time zones", "what": "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.", "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.", "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.", "checkCode": null, "fix": { "kind": "guide", "href": "https://github.com/CyberNative-AI/.github/tree/main/notes/javascript-dst-2026", "label": "Measured results per library and a check for your schedule (no tested fix)", "testedAt": null }, "sources": [ { "label": "GOV.UK: When do the clocks change?", "href": "https://www.gov.uk/when-do-the-clocks-change", "checkedAt": "2026-10-14" }, { "label": "PTB (Germany's national time authority): when summer time begins and ends", "href": "https://www.ptb.de/cms/ptb/fachabteilungen/abt4/fb-44/fragenzurzeit/fragenzurzeit03.html", "checkedAt": "2026-10-14" } ] }, { "id": "2026-11-01-canada-time-zone-change-runtimes", "added": "2026-10-18", "short": "Canada time change: Java, Go, PHP an hour off", "date": "2026-11-01", "dateEnd": null, "datePrecision": "day", "time": "02:00 local", "title": "Canada's 1 November time change: Java, Go, PHP, Kubernetes CronJobs and MySQL stay an hour off", "area": "Time zones", "what": "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.", "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.", "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.", "checkCode": "php -r 'echo timezone_version_get(), \"\\n\";'\nnode -p process.versions.tz\nTZ=America/Winnipeg date -d '2026-12-15 12:00Z' +%H:%M", "fix": { "kind": "tested", "href": "/guides/canada-time-zone-change-2026-runtimes/", "label": "Tested fixes for Java, PHP, Go, Kubernetes CronJobs and MySQL/MariaDB", "testedAt": "2026-10-14" }, "sources": [ { "label": "IANA time zone database 2026e release notes", "href": "https://data.iana.org/time-zones/tzdb/NEWS", "checkedAt": "2026-10-14" }, { "label": "Government of Ontario: permanent daylight saving time in parts of northwestern Ontario (13 October 2026)", "href": "https://news.ontario.ca/en/release/1008130/ontario_moving_to_permanent_daylight_saving_time_in_parts_of_northwestern_ontario", "checkedAt": "2026-10-14" } ] }, { "id": "2026-11-01-canada-time-zone-change-databases", "added": "2026-10-18", "short": "Canada time change: databases an hour off", "date": "2026-11-01", "dateEnd": null, "datePrecision": "day", "time": "02:00 local", "title": "Canada's 1 November time change: MongoDB, Elasticsearch, OpenSearch, Trino and DuckDB still an hour off", "area": "Time zones", "what": "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.", "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.", "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.", "checkCode": null, "fix": { "kind": "tested", "href": "/guides/canada-time-zone-change-2026-databases/", "label": "Tested fixes for MongoDB, Elasticsearch/OpenSearch, Trino and DuckDB", "testedAt": "2026-10-14" }, "sources": [ { "label": "IANA time zone database 2026e release notes", "href": "https://data.iana.org/time-zones/tzdb/NEWS", "checkedAt": "2026-10-14" } ] }, { "id": "2026-11-01-us-clocks-go-back-schedulers", "added": "2026-10-18", "short": "US clocks go back: some jobs run twice", "date": "2026-11-01", "dateEnd": null, "datePrecision": "day", "time": "02:00 local", "title": "US clocks go back: some JavaScript and n8n scheduled jobs run twice or at the wrong time", "area": "Time zones", "what": "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.", "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.", "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.", "checkCode": null, "fix": { "kind": "guide", "href": "https://github.com/CyberNative-AI/.github/tree/main/notes/javascript-dst-2026", "label": "Measured results per library and a check for your schedule (no tested fix)", "testedAt": null }, "sources": [ { "label": "NIST: Daylight saving time rules", "href": "https://www.nist.gov/pml/time-and-frequency-division/popular-links/daylight-saving-time-dst", "checkedAt": "2026-10-14" } ] }, { "id": "2026-11-02-github-macos-14-runner-retirement", "added": "2026-10-18", "short": "GitHub retires the macOS 14 runner", "date": "2026-11-02", "dateEnd": null, "datePrecision": "day", "time": null, "title": "GitHub Actions retires the macOS 14 runner image, and Xcode 15 and the iOS 17 simulators go with it", "area": "CI runners", "what": "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.", "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.", "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.", "checkCode": "rg -n --hidden --glob '*.yml' --glob '*.yaml' \\\n '\\bmacos-14(-large|-xlarge)?\\b' .github/workflows", "fix": { "kind": "guide", "href": "https://github.com/CyberNative-AI/.github/tree/main/notes/macos14-brownout#check-xcode-and-simulator-selections-too", "label": "Replacement by architecture, and which Xcode and simulators each image has", "testedAt": null }, "sources": [ { "label": "GitHub changelog: macOS 14 runner image retirement (1 October 2026)", "href": "https://github.blog/changelog/2026-10-01-github-actions-macos-14-runner-image-retirement/", "checkedAt": "2026-10-14" } ] }, { "id": "2026-11-16-usgs-waterservices-slowdown", "added": "2026-10-18", "short": "USGS WaterServices: 2 s delay per request", "date": "2026-11-16", "dateEnd": null, "datePrecision": "day", "time": null, "title": "USGS starts slowing every WaterServices request ahead of its shutdown", "area": "Data APIs", "what": "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.", "affected": "Scripts, dashboards and pipelines that call waterservices.usgs.gov, especially those making many requests or running under a timeout.", "check": "Search your code and configuration for the old host.", "checkCode": "grep -rn 'waterservices.usgs.gov' .", "fix": { "kind": "none", "href": "https://api.waterdata.usgs.gov/docs/ogcapi/migration/", "label": "USGS migration guide to the new Water Data APIs", "testedAt": null }, "sources": [ { "label": "USGS: WaterServices degradation and decommission schedule (18 September 2026)", "href": "https://waterdata.usgs.gov/blog/wdfn-waterservices-degradation/", "checkedAt": "2026-10-14" } ], "leadDays": 30 }, { "id": "2026-12-16-socrata-soda1-removal", "added": "2026-10-18", "short": "Socrata removes SODA1 rows.csv downloads", "date": "2026-12-16", "dateEnd": null, "datePrecision": "day", "time": null, "title": "Socrata removes its SODA1 API: rows.csv download links stop working", "area": "Data APIs", "what": "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.", "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.", "check": "Search your code for SODA1 download links, then paste each one into the checker on the guide page.", "checkCode": "grep -rn 'accessType=DOWNLOAD' .", "fix": { "kind": "tested", "href": "/guides/socrata-rows-csv-replacement/", "label": "Replacement URL plus pandas and R code that keeps the old column names and numbers", "testedAt": "2026-10-09" }, "sources": [ { "label": "Tyler Technologies (Socrata): Deprecation Roadmap", "href": "https://support.socrata.com/hc/en-us/articles/360008097514-Deprecation-Roadmap", "checkedAt": "2026-10-09" } ], "leadDays": 30 }, { "id": "2027-02-22-usgs-waterservices-decommissioned", "added": "2026-10-18", "short": "USGS WaterServices shut down", "date": "2027-02-22", "dateEnd": null, "datePrecision": "day", "time": null, "title": "USGS decommissions WaterServices: requests are redirected to a notice", "area": "Data APIs", "what": "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.", "affected": "Anything still calling waterservices.usgs.gov instead of the new Water Data APIs.", "check": "Search your code and configuration for the old host.", "checkCode": "grep -rn 'waterservices.usgs.gov' .", "fix": { "kind": "none", "href": "https://api.waterdata.usgs.gov/docs/ogcapi/migration/", "label": "USGS migration guide to the new Water Data APIs", "testedAt": null }, "sources": [ { "label": "USGS: WaterServices degradation and decommission schedule (18 September 2026)", "href": "https://waterdata.usgs.gov/blog/wdfn-waterservices-degradation/", "checkedAt": "2026-10-14" } ], "leadDays": 30 }, { "id": "2027-03-15-tls-100-day-certificates", "added": "2026-10-18", "short": "TLS certificate maximum drops to 100 days", "date": "2027-03-15", "dateEnd": null, "datePrecision": "day", "time": null, "title": "Publicly trusted TLS certificates drop to a 100-day maximum", "area": "Certificates", "what": "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.", "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.", "check": "Read your live certificate's dates (replace example.com with your host) to see how long your current certificates last.", "checkCode": "echo | openssl s_client -connect example.com:443 \\\n 2>/dev/null | openssl x509 -noout -startdate -enddate", "fix": { "kind": "none", "href": "https://cabforum.org/working-groups/server/baseline-requirements/requirements/", "label": "CA/Browser Forum Baseline Requirements (dates in section 1.2.2)", "testedAt": null }, "sources": [ { "label": "CA/Browser Forum TLS Baseline Requirements: maximum validity 100 days from 2027-03-15", "href": "https://cabforum.org/working-groups/server/baseline-requirements/requirements/", "checkedAt": "2026-10-14" } ], "leadDays": 60 } ] }