DEVOPS
Spin a war-room and pin the suspect deploy when a release fails
When a GitHub deployment status flips to failure, this workflow opens a Zoom incident bridge, gathers the commits since the last good deploy.
How it runs
The automated pipeline, trigger to output.
- TriggerGitHub deployment failedGitHub
- ActionFetch commits since last good deployGitHub
- ActionCreate Zoom incident bridgeZoom
- ActionOpen PagerDuty incidentPagerDuty
- OutputPost bridge + suspect commits to SlackSlack
What it does
A failed production deploy is the most common trigger for a war-room. This workflow reacts to a GitHub deployment failure by standing up a Zoom bridge and immediately surfacing the exact commits that shipped since the last healthy deploy — so the responders on the call already know what to roll back.
When to use it
Use it when deploys flow through GitHub Deployments or Actions and you want the diagnostic context (the suspect changeset and authors) waiting in the channel before the first responder even joins the call.
How it works
- 1A GitHub webhook fires on a deployment_status of `failure`.
- 2The workflow queries GitHub for the commit range between the failed deploy and the last successful one.
- 3Zoom creates an incident bridge named with the repo and deploy ref.
- 4A PagerDuty incident is opened and assigned to the service's on-call.
- 5Slack posts the bridge link plus a formatted list of suspect commits, authors, and PR links to the deploy channel.
Set it up
What you configure once, before turning it on.
- 1Connect GitHubRepos, issues, pull requests, actions.
- 2Connect ZoomMeetings, recordings, transcripts.
- 3Connect PagerDutyIncidents, on-call, escalations.
- 4Connect SlackChannels, DMs, threads, mentions.
- 5Set each agent's modelWe leave models unset so you pick the tier — fast + cheap, or top-quality.
- 6Tune it to your dataEdit the prompts, filters, and field mappings so it matches how your team works.
- 7Test, then turn it onRun once against a sample, confirm the output, then enable the trigger.
More DevOps workflows
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.
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.
Generate a weekly de-flake report and assign Linear cleanup tickets
On a weekly schedule, aggregates the current quarantine manifest and recent flake history, builds a prioritized report.
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-release tests from quarantine once they prove stable
Triggered by a webhook from a nightly stability runner, checks whether quarantined tests have passed enough consecutive runs, removes the stable ones from quarantine in GitHub.
Quarantine a test on demand from a PR comment command
Triggered when an engineer comments a quarantine command on a pull request, validates the test name, commits the quarantine change to that PR branch, opens a tracking issue.
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.