DEVOPS
Freeze deploys when Honeycomb SLO burn rate spikes
Watches a Honeycomb SLO burn-rate alert and, when error budget is burning too fast, automatically applies a deploy-freeze label to your GitHub repo and pins a notice in Slack…
How it runs
The automated pipeline, trigger to output.
- TriggerHoneycomb SLO fast-burn alert webhookHoneycomb
- LogicCompare burn rate to freeze threshold
- ActionApply deploy-freeze label + blocking check on repoGitHub
- ActionPost and pin freeze notice in SlackSlack
- OutputConfirm freeze active with SLO context
What it does
This template turns a Honeycomb fast-burn alert into an enforced engineering policy. When your SLO is consuming error budget faster than a safe threshold, it locks the repo against new deploys and tells the team why in one place — no manual judgment calls in the middle of an incident.
When to use it
Use it on a service with a defined Honeycomb SLO where shipping more code during a budget burn would compound risk. Best for teams that practice error-budget-based release gating but don't want to babysit dashboards.
How it works
- 1A Honeycomb burn-alert webhook fires when the SLO's fast-burn budget rate crosses your configured multiple.
- 2A logic step checks the burn-rate severity against your freeze threshold (e.g. 14.4x over one hour).
- 3If over threshold, an action adds a `deploy-freeze` label and a protected status check on the target GitHub repo so merges to main are blocked.
- 4A second action posts and pins a Slack message naming the SLO, current burn rate, and remaining budget.
- 5The output confirms the freeze is active and links the Honeycomb trigger for on-call context.
Set it up
What you configure once, before turning it on.
- 1Connect HoneycombDistributed traces and queries.
- 2Connect GitHubRepos, issues, pull requests, actions.
- 3Connect SlackChannels, DMs, threads, mentions.
- 4Set each agent's modelWe leave models unset so you pick the tier — fast + cheap, or top-quality.
- 5Tune it to your dataEdit the prompts, filters, and field mappings so it matches how your team works.
- 6Test, then turn it onRun once against a sample, confirm the output, then enable the trigger.
More DevOps workflows
Block costly Hugging Face Space hardware upgrades in PR review
When a pull request changes a Space's hardware config, it estimates the new monthly cost and posts a GitHub PR comment that flags upgrades crossing a budget ceiling.
Auto-spin a Zoom war-room when PagerDuty hits SEV-1
When a PagerDuty incident escalates to a critical severity, this workflow creates a dedicated Zoom meeting and posts the bridge link to the incident's Slack channel so responders…
Page on-call when a Hugging Face Space build is stuck or errored
Polls Hugging Face Space runtime status on a schedule and opens a PagerDuty incident when a Space sits in a build or error state past a deadline, with a Slack heads-up.
Slack-approved pause for idle Hugging Face Spaces
On a daily scan it finds idle paid Spaces and posts an interactive Slack approval; on approve it pauses the Space and logs the decision to a GitHub issue audit trail.
Hugging Face Spaces idle-runtime sweep with auto-pause
On a schedule, scans all Hugging Face Spaces for ones running idle past a threshold, pauses them to stop billing, and posts a Slack summary with the estimated monthly savings.
Open a Zoom war-room from a Datadog multi-alert storm
When a Datadog monitor crosses a critical threshold, this workflow dedupes against active incidents, and only for a genuinely new outage it creates a Zoom bridge.
Run it inside a business
This workflow drops into a full company template. Import the org, and this is one of the playbooks its agents run.
Run this workflow in your colony.
14-day trial. No DevOps. No Sales call. Provisioned in under a minute.