DEVOPS
On-merge deploy-correlation tracker that backfills lead time when shipped
When a GitLab MR merges it records an open lead-time entry in Postgres; a Honeycomb deploy marker later closes the matching entry with actual deploy time.
How it runs
The automated pipeline, trigger to output.
- TriggerGitLab MR merged webhookGitLab
- ActionInsert pending lead-time row in PostgresPostgres
- ActionReceive Honeycomb deploy markerHoneycomb
- LogicMatch deploy SHAs to open rows
- ActionClose rows with deploy time + lead timePostgres
- OutputNotify team in Slack on production arrivalSlack
What it does
Measures true change lead time by tracking each merged MR until it actually reaches production. On merge, it opens a pending lead-time record keyed by commit SHA in Postgres. When Honeycomb later signals a deploy containing that SHA, the workflow closes the record with the deploy timestamp, yielding precise per-change merge-to-deploy duration even when merges and deploys are decoupled.
When to use it
Use this when deploys lag merges unpredictably (batched releases, manual promotion) and SHA-range joins in a nightly batch would be lossy. It gives you accurate lead time per change rather than an approximation.
How it works
- 1A GitLab merge-request webhook trigger fires on each merged MR.
- 2Action inserts a pending lead-time row (SHA, team, merge time) into Postgres.
- 3A second path: a Honeycomb deploy marker arrives.
- 4Logic step matches the deploy's commit SHAs to open Postgres rows.
- 5Action updates matched rows with deploy time and computed lead time.
- 6Output notifies the team channel in Slack when a change reaches production.
Set it up
What you configure once, before turning it on.
- 1Connect GitLabRepos, MRs, pipelines, registry.
- 2Connect PostgresAny Postgres URL — query, write, migrate.
- 3Connect HoneycombDistributed traces and queries.
- 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.