I made a GitHub Action that opens an issue before a vendor breaks your build

#ai #githubactions #devops #opensource

Every few weeks some vendor retires something my code depends on. A runner label, a Lambda runtime, an OpenAI model, a GKE version. The notice exists - in a changelog, a deprecation table, an email to a billing inbox. We still find out when the build fails.

Dependabot tells you when a library is old. Nothing told me "this line in this repo stops working on Nov 2". So I made a small GitHub Action for that.

What it does

Once a week it reads your repo on the GitHub runner and looks for things that have a dated shutdown or price change. If it finds any, it opens one issue with the file and line, the date, days left and the fix. When you fix everything, the issue closes itself.

This is from the demo repo (full issue here):

Found 9 places hit by 9 vendor deadlines within 120 days.

[ ] GKE 1.31 extended support ends October 22, 2026 - 3 days left

infra/gke.tf:4 min_master_version = "1.31"

Fix: Upgrade the control plane, then each node pool, to 1.32 or newer before GKE does it for you.

[ ] OpenAI shuts down gpt-4, gpt-3.5-turbo, o1 and o4-mini on October 23 - 4 days left

src/ai/summarize.py:7 "gpt-4"

Fix: Change the model name: most go to gpt-5.6-sol or gpt-5.6-terra.

[ ] AWS Lambda Python 3.10 runtime deprecated October 31, 2026 - 12 days left

serverless.yml:4 runtime: python3.10

[ ] GitHub Actions macos-14 runners retire November 2, 2026 - 14 days left

.github/workflows/ci.yml:11 macos-14

Setup

One file, .github/workflows/deadline-check.yml:

name: Vendor deadline check
on:
  schedule:
    - cron: '17 6 * * 1'   # Mondays
  workflow_dispatch:
permissions:
  contents: read
  issues: write
jobs:
  deadlines:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: timetobail/deadline-check@v0

That's it. Options: days (default 120), fail-on-days if you want the job to fail when something is close, comment-on-pr.

What it knows about

114 rules for 94 dated changes, for example:

AI models: OpenAI (gpt-4, GPT-4o and 4.1 snapshots, TTS, Whisper), Gemini API and Vertex AI, Azure OpenAI, Amazon Bedrock, Claude
CI: GitHub Actions runners (macos-14, ubuntu-22.04), Azure Pipelines images, GitLab 20.0 removals, CircleCI images and APIs
Runtimes: AWS Lambda, Cloud Run functions, App Engine, Azure Functions, Heroku stacks
Kubernetes: GKE, EKS and AKS versions
Other: .NET 8/9, Prisma Accelerate, Bitbucket SSH host, Docker Content Trust

Every rule points to a dated change that comes from the vendor's own page (deprecation tables, changelogs, docs). No rumors, no "or later" dates.

Things I cared about

Your code never leaves the runner. The action makes one GET request for the public rules list. That's the only network call.
Strict rules. A false alarm is worse than a miss. "gpt-4" matches, "gpt-4o" doesn't. dotnet matches, dotnet-isolated doesn't. Comment lines are skipped.
One issue, not a flood. It updates the same issue every week.
Free. The action is MIT, the rules are open data (CC BY 4.0).

Links

Marketplace: https://github.com/marketplace/actions/time-to-bail-deadline-check
Code: https://github.com/timetobail/deadline-check
Demo issue: https://github.com/timetobail/deadline-check-demo/issues/1

If it misses something in your stack, or flags something it shouldn't, open an issue with a small sample - I'll add or fix the rule. And I'm curious: which deprecation surprised you the most this year?

Disclosure: I run timetobail.com, where the rules and the change pages live.

Top comments (2)

Yury Atrashkevich • Oct 20

Neither, actually. It doesn't watch dependencies or call any APIs.

It's a list of rules, one per dated vendor change. I take each change from the vendor's own deprecation page or changelog (date, what stops working, the fix), and write a strict pattern for how it shows up in a repo - "runs-on: macos-14" in workflows, runtime: python3.10 in serverless.yml, "gpt-4" in code, cluster version 1.31 in Terraform.

The action just reads the files on the runner and matches these patterns, so it's static and pretty boring on purpose. The hard part is keeping the list fresh and the patterns strict, so "gpt-4" matches but "gpt-4o" doesn't.

arcwrightai • Oct 20

Nice, proactive monitoring beats reactive debugging. How do you detect the breakage — dependency updates or API changes?