Most reliability work happens after something breaks.
An alert fires. Someone gets paged. The investigation begins. The same questions surface: what changed, which service is affected, what's the blast radius. And the same engineers answer them, again.
It works, until it stops scaling. Each alert waits for a person to start the investigation, and the same few engineers answer the same questions every time. More services and more alerts mean more pages for those same people.
NOFire Workflows are the answer to that cycle. They are always-on agents that respond to alerts, complete investigations, check production health, and act, without waiting for a human to start them. A trigger starts each run, so no one has to be paged to begin. The agent answers the recurring questions (what changed, which service is affected, what the blast radius is) from the production map.
What a Workflow Is
A workflow in NOFire is the combination of three things:
- A trigger: the event that starts it. A Slack alert. A completed investigation. A GitHub push. A scheduled cron. A webhook. A manual command from chat.
- Instructions: natural language that tells the agent what to do. Written by your team once, reused on every run.
- An output: where the result goes. A Slack channel, a thread reply, a webhook endpoint, or stored silently in the run history.
Every workflow runs against your production map: the live picture of your services, dependencies, recent deployments, and incident history. The agent doesn't just follow instructions; it understands your production.
Workflows in action: what proactive checks and responses they run
Workflows run two kinds of jobs. Proactive checks run on a schedule and look for trouble before an alert fires. Responses run when an event arrives and do the follow-up work an engineer would otherwise start by hand.
- Proactive checks: a health check every 15 minutes for drift below the alert threshold, a weekly production readiness review, and a daily compliance drift scan.
- Responses: a post-mortem when an investigation completes, a root cause investigation on
/investigate, post-deploy validation on every push to production, and a risk score on every pull request.
The next section covers the three workflows that ship with NOFire. The rest are in the section on building your own.
Three Workflows Ready Out of the Box
When you connect NOFire, three workflows are seeded automatically. You can edit them, disable them, or use them as a starting point for your own.
Proactive Health Check
Trigger: Scheduled every 15 minutes
What it does: Scans your highest-risk entities (ranked by alert frequency and dependency count) looking for error rates trending up below the alert threshold, latency increasing vs. the same window yesterday, and recent deployments that correlate with the drift. If degradation is found, it posts to #ops-proactive with the affected service, likely cause, and blast radius. It checks whether it already warned about the same entity in the last hour to avoid noise.
Output: Slack channel (#ops-proactive). Posts only when something needs attention.
This is the workflow that catches problems 15–20 minutes before your alerting system fires. The one that prevents the 3 AM page. It looks for error rates and latency trending the wrong way while they are still below the alert threshold. The warning reaches #ops-proactive with the likely cause and blast radius, so the team can act before the alert pages anyone.
Post-Mortem Analysis
Trigger: Investigation complete
What it does: Generates a structured post-mortem: timeline, root cause, impact assessment, what went well, what to improve, and actionable follow-ups. Checks the knowledge store for recurring patterns and flags if this root cause has appeared before.
Output: Slack channel (#post-mortems).
No one writes post-mortems at 3 AM. This workflow does it while the investigation is still fresh.
Investigate
Trigger: On-demand command (/investigate)
What it does: Starts or continues a convergent root cause analysis from chat. Pass it a service name, a symptom, or a time window and it runs multi-signal investigation across logs, metrics, traces, and deployment history, returning a draft diagnosis in the same thread.
Output: Slack thread reply.
Build your own workflows: customization and catalog options
The three defaults are a starting point. The catalog has more, and your team can build anything.
Write instructions in plain language. Pick the trigger. Choose where the output lands. Every workflow has access to your full production map, the same live data that powers NOFire's investigations.
Post-deploy validation. Triggered on every GitHub push to production. The agent waits 10 minutes for the deploy to settle, then compares error rates, latency p50/p95/p99, and throughput against the pre-deploy baseline. Checks logs for new error patterns that didn't exist before. Checks whether downstream services are showing degradation. If a regression is found, it identifies the specific commit and recommends a rollback. If healthy, it posts a green confirmation to #deploys.
Pre-merge risk assessment. Triggered on every pull request. The agent maps the changed files to entities in the production map and scores each affected entity for blast radius, incident history in the last 30 days, and active anomalies. Returns a risk score (LOW / MEDIUM / HIGH / CRITICAL) as a PR comment, giving teams a signal before anything ships.
Production readiness review. Scheduled weekly (Monday 9 AM). For every service in the cluster, the agent evaluates whether it's production-ready: metrics in the catalog, alerts configured, observability coverage, dependency blast radius, incident count in the last 30 days. Each service gets a verdict (READY / NEEDS ATTENTION / NOT READY) posted to #platform-team.
Compliance drift detection. Scheduled daily at 6 AM. Scans for new compliance drift since yesterday using AWS Config and CloudTrail: security groups open to the internet, unencrypted RDS or S3 buckets, IAM policies with unexpected admin access. Only reports what is new, so the channel stays signal-dense. Posted to #security-compliance.
Weekly operational report. Scheduled every Monday morning. Summarizes total incidents by severity vs. the previous week, top 5 noisiest entities, MTTR by team and service, repeat offenders, and deployment risk summary. Posted to #eng-leadership before the first standup.
Workflows and the NOFire MCP server read the same production map. To give other agents, such as Claude Code or Cursor, the same context, see building secure, agent-driven SRE workflows with MCP.
How It Works
Each workflow runs as an isolated agent invocation. The trigger fires, the agent receives the trigger context alongside your team's instructions, and it runs against the production map. Results are delivered and stored in the run history for audit and review.
Triggers, instructions, and delivery are fully decoupled. A Slack alert doesn't know about your instructions. Your instructions don't know about the delivery channel. The agent sits in between, with access to everything that matters.
Idempotency is handled at the run level. The same alert firing twice won't produce duplicate investigations.
Trigger sources currently supported: Slack alerts, Grafana IRM incidents, GitHub events (push, pull_request, and others), investigation completions, webhooks, scheduled cron, and on-demand commands.
The Shift This Makes
Monitoring tells you something broke. Workflows understand what broke and often act on it before you've had a chance to open your laptop.
The health check fires at 3:15 AM. It spots latency drift on the checkout service, below the alert threshold but trending. It cross-references recent deployments, finds a correlation, and posts to #ops-proactive with the affected service and a likely cause. By the time the engineer wakes up, the signal is already there.
None of that is magic. It is a well-written workflow running against a complete picture of production. The health check could name a likely cause because the production map holds recent deployments, dependencies and incident history in one place. The agent read the latency drift and the deploy side by side and found the correlation.
Workflows are available now. If you're already on NOFire, they're in your sidebar. If you're new, start here and they'll be ready when you connect your first integration.
