Production incidents expose what a coding agent cannot learn from the repository alone. Today we're bringing Steadwing into the agent workflow and closer to the evidence from production with our new Agent Skill and Python + Node SDKs.

During an incident, engineers are manually searching logs across CloudWatch, Elasticsearch, Loki or wherever the logs live. They're looking around time ranges, crafting queries and hoping they're looking in the right place. Steadwing connects to CloudWatch, GCP Logging, Elasticsearch, Mezmo, Scalyr and many more. When an investigation triggers, it queries all connected log sources in parallel searching for error messages, stack traces and anomalies around the incident timeframe. The relevant log lines show up in the RCA with timestamps and context. So engineers don't search for logs. For teams running multiple log platforms across different services: Steadwing searches all of them simultaneously.

Steadwing doesn't replace your observability or alerting tools. It connects them altogether. When PagerDuty fires an alert, Steadwing pulls incident timelines, escalation data and response metrics. Simultaneously, it queries Datadog for logs, APM data, and triggered monitors around the incident timeframe. The result: your on-call engineer gets a complete picture alert context from PagerDuty correlated with logs from Datadog, code changes from GitHub, and performance data from your AWS all in one RCA. Engineering team spent years building the observability stack. We make it work as one system during incidents.

Most production incidents trace back to something that changed recently. A deploy. A config update. A merged PR. Steadwing connects to your GitHub or GitLab repos and automatically correlates incidents with recent commits, deployments and releases. When something breaks, the RCA shows you which specific change caused it down to the exact commit and code diff. No more asking "did anyone deploy something?" in Slack. No more manually scanning CI/CD pipelines. The correlation happens automatically as part of the investigation.

Engineers work in Slack already during incidents. That's where they get the alert, they coordinate the response and share updates. Steadwing is a perfect fit for Slack. When an alert comes in, it automatically investigates your entire stack logs, metrics, traces, code changes and delivers the root cause analysis right back into Slack. No context switching. No opening multiple tabs. The RCA appears where the team is already working with links back to each source tool for evidence. Engineers won't have to learn a new interface or change their workflow. They get the diagnosis where they already are.

Here's a number that doesn't show up in most engineering dashboards. Each after-hours incident costs roughly 4–6 hours of productive engineering time the following day. Not the incident itself. The day after. 2 hours on post-mortem docs and Slack async. 1 hour in a meeting too tired to contribute. 1 hour of feature work that just doesn't happen. For an on-call engineer handling 3 incidents a week which nearly half of SREs report that's 50+ hours of lost productivity a month. This never appears in your MTTR dashboard. But it shows up in velocity and attrition. The real ROI of reducing on-call burden isn't faster incidents. It's preserving the other 99% of your team's engineering time.

The AI for incident response space went through two very different eras. AIOps was about anomaly detection. Structured metrics. The output was a correlation score and an alert. No diagnosis. No code understanding. Remediation was mostly "roll back". LLM-powered RCA is a completely different approach. It reads logs, metrics, traces, code diffs, configs, and deploy history. It generates a natural language root cause analysis with an evidence chain you can actually verify. It references past incidents. It suggests fixes on code level, infra and CI/CD. The shift isn't just better models. It's a fundamentally different architecture from pattern-matching on metrics to actually understanding what your system is doing and why it broke. That's the approach we took with Steadwing to show evidence-based RCA with fixes you can verify and immediately ship.

30 alerts in 2 minutes. Your on-call engineer opens Slack and gets overwhelmed. It's rarely 30 problems, usually one issue causing a chain reaction. They end up triaging each alert & 20 minutes are gone. We group alerts into 1 incident & give root cause for it.

We’re now SOC 2 Type II compliant!