ENGINEERING

Block a GitHub PR merge when the target service is over its error budget

On pull request events, checks the target service's Honeycomb burn rate and posts a passing or failing GitHub commit status.

CategoryEngineering
Enginesim
Difficultyintermediate
Triggerwebhook
Steps5
Setup~15 min

How it runs

The automated pipeline, trigger to output.

  • TriggerGitHub pull_request webhookGitHubGitHub
  • ActionFetch target service SLO burn rate from HoneycombHoneycomb
  • LogicPass or fail against budget gate
  • ActionSet GitHub commit status checkGitHubGitHub
  • OutputComment on PR with burn rate on failureGitHubGitHub

What it does

Moves the error-budget gate left to the pull request. When a PR opens or updates against a service that is currently burning budget too fast, this workflow sets a failing GitHub status check and leaves a comment explaining the gate, so the change cannot merge until reliability recovers or a human overrides. When the service is healthy, it sets a passing check.

When to use it

Use it when you want error-budget policy enforced at merge time as a required status check, giving authors a clear signal before code ever reaches Vercel. Best for repos that already use required GitHub checks.

How it works

  1. 1A GitHub pull_request webhook triggers on open or synchronize.
  2. 2The workflow resolves the PR to its target service and fetches that SLO's burn rate from Honeycomb.
  3. 3A branch decides pass or fail against the budget gate.
  4. 4It sets the GitHub commit status check accordingly via the API.
  5. 5On failure it comments on the PR with the burn rate and a link to the SLO so the author knows why the merge is blocked.

Set it up

What you configure once, before turning it on.

  1. 1
    Connect GitHubRepos, issues, pull requests, actions.
  2. 2
    Connect HoneycombDistributed traces and queries.
  3. 3
    Set each agent's modelWe leave models unset so you pick the tier — fast + cheap, or top-quality.
  4. 4
    Tune it to your dataEdit the prompts, filters, and field mappings so it matches how your team works.
  5. 5
    Test, then turn it onRun once against a sample, confirm the output, then enable the trigger.

Run this workflow in your colony.

14-day trial. No DevOps. No Sales call. Provisioned in under a minute.