DEVOPS
Reconcile running containers against EOL base layers via Datadog
Pulls the live container inventory from Datadog, maps each running image to its base layer's support status.
How it runs
The automated pipeline, trigger to output.
- TriggerDaily schedule starts the reconciliation
- ActionQuery Datadog for the live container image inventoryDatadog
- ActionResolve base layers and look up EOL status over HTTPHTTP webhook
- LogicIsolate EOL base layers running in production
- ActionOpen a rebuild issue per affected image in GitHubGitHub
- OutputSend a prioritized Slack alert to on-callSlack
What it does
This workflow looks at what is actually running in production, not just what's in your repos. It reads the container image inventory from Datadog, identifies the base layer behind each image, checks the support status, and flags any EOL base layer that is currently deployed and handling load.
When to use it
Use this when image drift is your real problem — old containers that never got redeployed and now run on unsupported bases. It catches the gap between what the registry says and what the fleet is doing.
How it works
- 1A daily schedule starts the reconciliation.
- 2The workflow queries Datadog for the active container inventory and the images each host is running.
- 3For each distinct image it resolves the base layer and queries the EOL status over HTTP.
- 4A logic step isolates EOL base layers that are live in production.
- 5For each finding it opens a GitHub issue tagged for rebuild with the affected services listed.
- 6A Slack alert names the services and their EOL deadline so on-call can prioritize.
Set it up
What you configure once, before turning it on.
- 1Connect DatadogMetrics, traces, log search.
- 2Connect HTTP webhookTrigger any URL on agent actions.
- 3Connect GitHubRepos, issues, pull requests, actions.
- 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.