Written by: Nimesh Chakravarthi, Co-founder & CTO, Struct | Last updated: June 25, 2026
Key Takeaways for AI-Driven Triage
- Traditional manual incident triage at 3 a.m. forces engineers to juggle multiple observability tools, driving up MTTA and MTTR while leaving blast radius unknown for the first 20 minutes.
- AI-driven triage automation, as used by Struct customers, compresses a 45-minute manual investigation into a 5-minute review, delivering an 80% reduction in triage time.
- The 4-stage maturity model provides a clear progression: Stage 1 is fully manual, Stage 2 adds alert enrichment, Stage 3 introduces hypothesis-ranking agents, and Stage 4 enables fully autonomous first-pass investigation before an engineer opens a laptop.
- Key benefits across stages include fewer tools touched per incident, lower junior-engineer escalation rates, and faster onboarding to first solo on-call shifts, all while maintaining SOC 2 and HIPAA compliance.
- Struct automates your on-call runbook so teams can start reducing triage time by 80% with their existing stack.
Stage 1 – Manual Triage as the Baseline
Goal: Acknowledge the alert and determine blast radius through direct human investigation. Owners: Senior SREs and backend engineers. Inputs: Raw Prometheus/Loki metrics, OpenTelemetry traces, PagerDuty or Slack trigger. Outputs: Verbal incident summary, manually assembled timeline. Trade-offs: Zero tooling cost, maximum cognitive load and MTTR.
At Stage 1, the data pipeline is straightforward: Prometheus scrapes service metrics, Loki aggregates logs, OpenTelemetry traces propagate through services, an alert rule fires a PagerDuty notification, and the engineer is paged into a Slack channel. Every subsequent step is manual. The engineer must authenticate into each observability platform, filter by time window, and mentally join disparate data sources without a unified view.
The table below quantifies how this manual approach compares to full automation and shows how tool-hopping and human-only investigation translate into measurable delays.
| Metric | Stage 1 (Manual) | Stage 4 (Automated) | Change |
|---|---|---|---|
| Avg. triage time | 30–45 min | under 10 min | −70%+ |
| Tools touched per incident | 4–6 | primarily Slack | Significant reduction |
| Junior-engineer escalation rate | High | Low | Significant reduction |
| Setup time | N/A | ~10 min | — |
Stage 2 – Alert Enrichment and Basic RAG in Slack
Goal: Attach structured context to every alert automatically before a human reads it. Owners: SRE team lead, platform engineer. Inputs: Alert payload, log index, basic runbook documentation. Outputs: Enriched Slack message with service owner, recent deploys, and error rate delta. Trade-offs: Reduces MTTA, does not yet rank hypotheses or confirm root cause.
Stage 2 adds a retrieval-augmented generation (RAG) layer that enriches alerts with context. When an alert fires, a lightweight enrichment pipeline queries the log store and attaches relevant details to the Slack notification. The YAML snippet below is a copy-paste starting point for a Prometheus Alertmanager webhook that forwards enriched payloads to a Slack channel.
# alertmanager-enrichment.yaml receivers: - name: 'slack-enriched' slack_configs: - api_url: 'https://hooks.slack.com/services/YOUR/WEBHOOK/URL' channel: '#on-call-alerts' title: '{{ .GroupLabels.alertname }}' text: | *Severity:* {{ .CommonLabels.severity }} *Service:* {{ .CommonLabels.service }} *Error Rate Delta:* {{ .CommonAnnotations.error_rate_delta }} *Last Deploy:* {{ .CommonAnnotations.last_deploy_sha }} *Runbook:* {{ .CommonAnnotations.runbook_url }} route: receiver: 'slack-enriched' group_by: ['alertname', 'service'] group_wait: 30s repeat_interval: 4h With enrichment in place, engineers can issue Slack bot commands such as @struct investigate #incident-1234 or @struct blast-radius service=payments to retrieve additional context without leaving the channel.
The comparison below highlights how Stage 2 builds on Stage 1 by adding context at alert time while still relying on humans for diagnosis.
| Capability | Stage 1 | Stage 2 |
|---|---|---|
| Alert context on receipt | Raw payload only | Service owner, deploy SHA, error delta |
| Runbook linkage | Manual lookup | Inline annotation |
| Hypothesis generation | None | None (enrichment only) |
See how Struct enriches your alerts automatically
Stage 3 – Hypothesis-Ranking Agent for Root Cause
Goal: Surface the most probable root cause from a ranked list of hypotheses before the engineer begins manual investigation. Owners: Senior SRE, engineering manager. Inputs: Enriched alert, RAG index over runbooks and postmortems, trace and log corpus. Outputs: Ranked hypothesis list with supporting evidence and confidence scores. Trade-offs: Requires a well-maintained runbook and postmortem corpus, accuracy degrades with sparse telemetry.
At Stage 3, a RAG agent indexes the team's historical runbooks and postmortem documents. When an alert fires, the agent retrieves semantically similar past incidents, extracts resolution patterns, and feeds them into a hypothesis-ranking engine alongside live telemetry. The result is a prioritized list, for example, "Hypothesis 1: database connection pool exhaustion (confidence 87%); Hypothesis 2: upstream rate-limit breach (confidence 61%)", delivered directly into the Slack thread.
The hypothesis-ranking engine performs regression analysis across recent metric windows and correlates anomalies across services. Struct performs regression analysis, correlates anomalies, and generates impact summaries as part of this automated reasoning layer.
The table below shows how Stage 3 extends Stage 2 by moving from enriched alerts to concrete, ranked hypotheses that guide the engineer's next step.
| Capability | Stage 2 | Stage 3 |
|---|---|---|
| Root cause identification | None | Ranked hypotheses with confidence |
| Historical pattern matching | None | RAG over runbooks & postmortems |
| Engineer action required | Interpret enriched alert | Validate top hypothesis |
Stage 4 – Autonomous First-Pass Investigation With Struct
Goal: Complete the entire context-gathering, correlation, and root-cause identification cycle before the on-call engineer opens a laptop. Owners: Any engineer on rotation, including junior ICs. Inputs: Alert trigger, full observability stack, code repository, custom runbooks. Outputs: Dynamically generated dashboard with unified timeline, confirmed root cause, blast radius, and suggested fix, plus optional PR creation. Trade-offs: Requires connected integrations, ephemeral log access must satisfy compliance requirements.
Struct is an AI agent that automatically root-causes engineering alerts by pulling and analyzing metrics, logs, traces, monitors, and code. At Stage 4, the investigation becomes fully autonomous. The moment an alert fires in a designated Slack channel or PagerDuty policy, Struct begins querying every connected data source in parallel, including Datadog, AWS CloudWatch, GCP Logs, Azure Traces, Sentry, and Prometheus/Loki, and joins the results into a single, issue-specific dashboard. As co-founder Deepan Mehta states: "Struct gets you from alert → root cause before you even open your laptop."
Because Stage 4 handles production incidents autonomously, deployment speed and compliance become critical. Struct deploys in 5–10 minutes, integrates with leading observability platforms, Slack, GitHub, Linear, and is fully SOC 2 and HIPAA compliant. Once root cause is confirmed, Struct hands off context to a local CLI, an AI coding agent, or generates a pull request directly in GitHub, which closes the loop from alert detection to code resolution without requiring a senior engineer to orchestrate each step.
The comparison below highlights how Stage 4 differs from Stage 3 by removing the need for engineer-initiated investigations and standardizing compliance.
| Capability | Stage 3 | Stage 4 (Struct) |
|---|---|---|
| Investigation trigger | Engineer-initiated | Fully automatic on alert fire |
| Time to root cause | 10–20 min | under 10 min |
| Compliance | Varies | SOC 2 & HIPAA |
Start autonomous investigations in 10 minutes
How AI Triage Fits Into Existing Engineering Operations
The 4-stage model fits into existing engineering workflows without a rip-and-replace of current tooling. Alert triggers continue to originate from existing monitoring rules and on-call policies. Struct listens passively to designated Slack channels or ticketing integrations and fires investigations in the background. Engineers receive findings in the same Slack thread where they already coordinate incident response, which preserves communication continuity.
Observability platforms remain the authoritative data sources, and Struct queries them ephemerally rather than duplicating data. Code context flows from GitHub, enabling Struct to correlate a spike in error rates with a specific commit or deployment event. Ticketing systems such as Linear, Jira, or Asana receive structured incident summaries automatically, which reduces the manual documentation burden that typically follows resolution.
Measurement and Continuous Improvement for AI Triage
Four primary KPIs govern the effectiveness of AI triage automation: MTTR, MTTA, alert-noise ratio (the percentage of alerts requiring human intervention), and junior-engineer onboarding time to first solo on-call shift. A quarterly review cadence, comparing rolling 90-day averages against the pre-automation baseline, provides sufficient data to tune alert thresholds, expand runbook coverage, and adjust Struct's composable widget configurations.
The KPI table below connects those quarterly reviews to concrete targets so teams can see whether automation is delivering meaningful operational gains.
| KPI | Pre-Automation Baseline | Post-Automation Target |
|---|---|---|
| Avg. investigation time | 30–45 min | under 10 min |
| MTTR (triage phase only) | 45 min | under 10 min |
| Alerts requiring escalation | High proportion | Reduced via automated filtering |
| Junior IC first solo shift | Weeks to months | Days with Struct runbook context |
Common Pitfalls When Automating Incident Triage
Insufficient telemetry. AI triage agents cannot infer system state from code alone and need structured telemetry to reason about failures. Without structured logging, trace IDs, or configured alert rules, the agent has no reliable data to analyze, which results in low-confidence outputs. To avoid this, instrument services with correlation IDs and ensure Sentry, Datadog, or equivalent platforms are capturing exceptions before enabling automated investigations.
Tribal-knowledge loss. When senior engineers leave or rotate off on-call, undocumented debugging patterns disappear with them, which leaves junior engineers guessing. Struct's custom runbook feature addresses this directly by turning those patterns into explicit procedures. Teams paste internal procedures into Struct so the AI follows the same diagnostic steps a senior engineer would, preserving institutional knowledge in a queryable, always-available form.
Over-automation risk. Granting an AI agent write access to production systems without a human confirmation step introduces unacceptable risk for most organizations. Struct's phased autonomy model keeps the first-pass investigation fully automated while requiring explicit engineer approval before any code change or infrastructure modification executes, which maintains governance without sacrificing speed.
Frequently Asked Questions
What is the minimum tooling maturity required to use Struct?
The ideal starting point is a team already using at least one observability platform (Datadog, AWS CloudWatch, GCP Logs, Prometheus/Loki, or equivalent), a code repository on GitHub, and Slack or PagerDuty for alert routing. Struct requires these integrations to query live telemetry. Teams without structured logging or alert rules will need to establish basic observability hygiene before automated investigations can produce high-confidence outputs.
Can Struct be used if our logs cannot leave our VPC?
Struct currently requires access to logs and observability context via its integration layer (AWS, GCP, Datadog, and similar platforms). For organizations with strict enterprise policies mandating full on-premise deployment where no data can leave the internal network, Struct is not the right fit at this time. For the vast majority of Seed-to-Series-C companies, Struct's SOC 2 Type II and HIPAA compliance, combined with ephemeral log processing, satisfies security and compliance requirements.
How does Struct help junior engineers handle on-call safely?
Struct acts as an automated senior engineer for the first pass of every incident. When an alert fires, Struct delivers a fully contextualized starting point, including blast radius, root cause hypothesis, supporting evidence, and suggested next steps, directly in Slack before the junior engineer has to make any diagnostic decisions. This removes the dependency on tribal knowledge and allows new hires to manage on-call rotations with confidence much earlier than they could through traditional mentorship alone.
How long does setup actually take?
Setup takes 5 to 10 minutes. The process involves three authentication steps: connect your issue source (Slack or a ticketing system), connect your code repository (GitHub), and connect your observability context (Datadog, CloudWatch, or equivalent). Once authenticated, auto-investigations can be enabled immediately. No lengthy enterprise deployment, professional services engagement, or weeks of configuration are required.
Can Struct follow our team's specific on-call procedures?
Yes. Struct supports custom runbooks, correlation ID formats, and composable widgets. Teams paste their internal on-call procedures directly into Struct, and the AI follows those exact steps when an alert fires. Composable widgets allow builders to guarantee that specific charts, log queries, or data sources are always included in the investigation output for particular alert types, which ensures the automated investigation mirrors what a senior engineer would do manually.
Conclusion: Move From Manual Triage to Autonomous Investigation
The 4-stage maturity model provides a clear, measurable path from manual 3 a.m. log-hunting to fully autonomous first-pass investigation. Stage 1 establishes the painful baseline. Stage 2 removes context-gathering overhead through alert enrichment. Stage 3 surfaces ranked hypotheses from historical runbooks and postmortems. Stage 4, delivered by Struct, completes the entire investigation before the engineer opens a laptop, with rapid setup, SOC 2 and HIPAA compliance, and a seamless GitHub hand-off for resolution.
Struct customers consistently achieve the 80% triage reduction outlined in this model, which validates the maturity framework against real production workloads. The 30-day risk-free pilot means there is no long-term commitment required to test these gains against your own stack.
See Struct handle your next incident before your team wakes up
