DEV Community: Can Bilmez

GitHub self-hosted runner brownouts start Monday. Here's how to find which runners will stop taking jobs

Can Bilmez — Sat, 05 Sep 2026 10:35:37 +0000

If you run self-hosted GitHub Actions runners, put this date in your calendar: September 25, 2026. That's when GitHub permanently stops queuing jobs to runners on outdated versions. Before that, brownouts: Sep 7, 9, 11, 14, 16, 18 — on Config + Runtime days, outdated runners don't register and don't execute jobs.

The failure mode is quiet. Nothing in your workflow errors out. The runner log says Runner version v2.xxx.0 is deprecated and cannot receive messages and every job targeting it sits in Queued. If you use Actions Runner Controller, auto-update is disabled by design, so the image tag in your Helm values is effectively a scheduled outage with an unknown date.

What changed on September 3

GitHub shipped an endpoint that returns the end-of-life date for any runner version:

gh api orgs/<org>/actions/runners/deprecations/2.334.0

{
  "runner_version": "2.334.0",
  "runtime_deprecates_at": "2026-08-10T00:00:00Z",
  "registration_deprecates_at": "..."
}

Two things I learned running this against real versions:

The documented rule is "30 days after release", but the API returns roughly 63–71 days for current versions. If you were computing this from release dates, your numbers are wrong in both directions.
The runner list endpoint now includes each runner's version, so you don't need an agent on the machines.

One command for the whole fleet

I wrapped the two endpoints in a small open-source gh extension:

gh extension install canblmz1/gh-runner-eol
gh runner-eol audit <org> --scan .

43 self-hosted runners · 3 versions · 4 pinned refs in .

  OVERDUE   18 runners   v2.334.0   runtime support ended 2026-08-10   26 days overdue
  WARNING   12 runners   v2.336.0   runtime support ends 2026-09-15   10 days left
  OK        13 runners   v2.337.0   no end-of-life scheduled

Pinned in source
  OVERDUE   Dockerfile:1           ghcr.io/actions/actions-runner:2.335.0   22 days overdue
  WARNING   deploy/values.yaml:5   ghcr.io/actions/actions-runner:2.336.0   10 days left

--scan is the part I care about most: it greps Dockerfiles, ARC Helm values, RUNNER_VERSION= variables and download URLs for pinned versions, and resolves each one against the API. Those are the runners you haven't scaled up yet — a live-runner dashboard can't see them.

It also runs as a GitHub Action with SARIF output, so a pinned line shows up as a Code Scanning annotation in the PR that introduces it, and exits non-zero on overdue so a weekly schedule can page you.

- uses: canblmz1/gh-runner-eol@v0
  with:
    target: my-org
    token: ${{ secrets.RUNNER_EOL_TOKEN }}
    scan: .
    format: sarif
- uses: github/codeql-action/upload-sarif@v4
  with:
    sarif_file: runner-eol.sarif

Gotchas

The workflow GITHUB_TOKEN cannot read self-hosted runners (403). Use a fine-grained PAT or GitHub App token with Self-hosted runners: read (org) or Administration: read (repo). Or run mode: scan for source-only.
It's read-only and deliberately does not upgrade or manage runners. ARC, GARM and friends do that; this only answers "what breaks, and when".

Repo: https://github.com/canblmz1/gh-runner-eol (MIT). If it misses a pinned-version shape in your repo, there's an issue template for exactly that — a regex and a test is a 10-line PR.

**

I Built Tautest: A Mutation Testing Workflow for AI-Written Tests

Can Bilmez — Mon, 11 May 2026 00:13:59 +0000

AI coding agents are getting really good at writing tests.

But I kept running into one uncomfortable problem:

Passing tests do not always mean strong tests.

Sometimes an AI agent writes tests that pass, but those tests only confirm that the current implementation runs. They do not necessarily prove that the behavior is protected.

That is why I built Tautest.

Tautest is an open-source CLI and GitHub Action that runs mutation testing on changed source lines, finds weak tests, and generates an AI-ready fix prompt for Claude Code, Cursor, Codex, or human reviewers.

GitHub:

https://github.com/canblmz1/tautest

npm package:

https://www.npmjs.com/package/tautest

The problem

Let’s say your code has a condition like this:

if (age >= 65) {
  return subtotal * 0.2;
}

Your normal tests might pass.

But what if this condition is mutated to:

if (age > 65) {
  return subtotal * 0.2;
}

If your tests still pass, then the exact boundary at 65 is not protected.

That is a weak test.

This is the kind of thing Tautest is designed to expose.

Demo

Regular tests pass, but Tautest finds a surviving mutant that the tests missed. After adding the missing boundary test, the mutation score improves to 100%.

What Tautest does

Tautest is not a mutation testing engine.

It uses StrykerJS as the mutation testing engine and adds a workflow layer around it.

Tautest:

reads changed source lines from git diff
runs StrykerJS mutation testing only on those changed lines
parses surviving mutants
generates Markdown, JSON, and terminal reports
writes an AI-ready fix prompt
can post a sticky GitHub PR comment
supports Vitest
has Jest beta support

The goal is simple:

Do not just ask whether the tests pass. Ask whether the tests fail when the behavior is mutated.

Example output

A regular test run can be green:

Test Files  1 passed
Tests       3 passed

But Tautest can still find a surviving mutant:

Tautest: MIXED (75.00%, threshold 60.00%)
Killed: 3 | Survived: 1 | No coverage: 0

Top surviving mutants:
- src/discount.ts:2 EqualityOperator

The surviving mutant:

age >= 65  ->  age > 65

After adding the missing boundary test:

it("applies the senior discount at exactly 65", () => {
  expect(calculateDiscount(65, 80)).toBe(16);
});

Tautest reports:

Tautest: STRONG (100.00%, threshold 60.00%)
Killed: 4 | Survived: 0

The AI fix prompt workflow

One thing I wanted Tautest to do was help AI coding agents write better tests without letting them rewrite production code.

So Tautest generates a file:

.tautest/fix-prompt.md

The prompt includes rules like:

do not change production code
only edit or add test files
every new test must pass against the original code
every new test must fail against the mutant behavior
do not weaken existing assertions
do not write filler tests like expect(true).toBe(true)

The workflow becomes:

Run Tautest.
Open .tautest/fix-prompt.md.
Paste it into Claude Code, Cursor, Codex, or use it yourself.
Add the missing test.
Run your normal tests.
Run Tautest again.

Install

For Vitest projects:

pnpm add -D tautest @stryker-mutator/core @stryker-mutator/vitest-runner
pnpm exec tautest init --yes --runner vitest --no-install
pnpm exec tautest doctor
pnpm exec tautest run --base origin/main

For Jest projects, Jest support is currently beta:

pnpm add -D tautest @stryker-mutator/core @stryker-mutator/jest-runner
pnpm exec tautest init --yes --runner jest --no-install

GitHub Action usage

Tautest also ships with a GitHub Action that can run on pull requests and post a sticky PR comment.

name: Tautest

on:
  pull_request:

permissions:
  contents: read
  pull-requests: write

jobs:
  tautest:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - uses: actions/setup-node@v4
        with:
          node-version: 20

      - uses: pnpm/action-setup@v4
        with:
          version: 10

      - run: pnpm install --frozen-lockfile
      - run: pnpm build

      - uses: canblmz1/tautest/packages/github-action@v1
        with:
          base: ${{ github.base_ref }}
          threshold: 60
          comment: changes
          cache: true

Important notes:

fetch-depth: 0 is required because Tautest needs git history.
pull-requests: write is required for sticky PR comments.
The v1 action currently ships from the monorepo path.

What Tautest does not do

Tautest is intentionally limited.

It does not:

implement its own mutation engine
replace StrykerJS
call any LLM API
prove that your tests are perfect
fully support monorepos in v1
classify AI-written tests with certainty

It is a deterministic workflow:

changed source lines -> mutation testing -> surviving mutants -> report -> fix prompt

Why I built it

AI coding agents are useful, but I do not want to blindly trust generated tests.

I wanted a workflow where an AI agent can write or improve tests, but a deterministic tool checks whether those tests actually protect behavior.

That is the main idea behind Tautest.

It is not:

AI wrote tests, so trust them.

It is:

AI wrote tests, now mutate the changed code and see whether those tests actually fail.

Current status

Tautest v1.0.0 is published.

Validated before v1:

tautest@1.0.0 published
@tautest/core@1.0.0 published
Release Readiness workflow passed
source-changing PR smoke passed
mutation run completed in GitHub Actions
JSON output parsed
sticky PR comment create and update verified
artifact upload verified

Roadmap

Some things I want to improve next:

Node 24 GitHub Action runtime migration
better cache observability
monorepo beta support
standalone GitHub Action repo
PR line annotations
more Jest fixtures