Written by: Nimesh Chakravarthi, Co-founder & CTO, Struct | Last updated: June 30, 2026
Key Takeaways
- Manual incident triage often takes 30–45 minutes per alert as engineers bounce between PagerDuty, Datadog, Sentry, and GitHub. This delay inflates MTTR and drains people during 3 a.m. incidents.
- Automated triage with Struct cuts that workflow to under 10 minutes by pulling alert sources, observability tools, and code repos into a single investigation thread.
- Seven repeatable steps connect alerts, map integrations, deduplicate, correlate signals, enrich runbooks, generate dashboards, and hand off to PR. Together, they deliver an 80% reduction in triage time.
- Teams that baseline MTTR, review weekly, and keep runbooks current see lasting gains in delivery speed and junior-engineer confidence on call.
- Struct replaces manual log-hunting with instant, context-rich root-cause summaries so engineers can focus on fixes instead of data gathering.
Step 1: Connect Alert Sources into Struct
Goal: Create a single, reliable entry point for every alert so no incident is missed and every investigation starts automatically.
Persona: Engineering Manager or senior IC configuring the initial integration.
Inputs: Slack alerting channels, PagerDuty policies, Linear/Jira queues.
Outputs: A unified trigger layer that fires an automated investigation the moment an alert lands.
Point Struct at the Slack channels where your monitoring tools already post. The configuration uses a single OAuth connection, so you avoid custom webhook plumbing. For teams routing through PagerDuty, add Struct as a service extension so every high-urgency page also spawns an investigation thread.
The following configuration shows how to connect key channels, enable auto-investigation, and filter to P1 and P2 alerts so early setups avoid overload:
# Slack channel config - paste into Struct's integration settings alert_sources: slack: channels: - "#alerts-production" - "#alerts-payments" auto_investigate: true severity_filter: ["P1", "P2"] pagerduty: service_ids: ["PXXXXXX"] escalation_policy: "primary-oncall" Trade-off: Connecting every noisy channel immediately increases investigation volume. Start with P1 and P2 channels and expand once deduplication in Step 3 is tuned.
See how Struct connects your alert sources in under 5 minutes
Step 2: Map Observability and Code Integrations for Rich Context
Goal: Give the automated triage engine access to every data source it needs to produce an accurate root-cause summary.
Persona: SRE or backend engineer who owns the observability stack.
Inputs: Datadog API keys, GitHub OAuth, AWS CloudWatch IAM role, Sentry DSN, GCP/Azure credentials.
Outputs: A connected context graph that Struct queries automatically during each investigation.
With alert sources connected, Struct still needs diagnostic data to explain why an alert fired. Observability and code integrations supply that context so investigations move beyond “an alert triggered” to “this specific change caused the failure.” Struct integrates with leading observability platforms, Slack, GitHub, and Linear and deploys in five to ten minutes. The Datadog and GitHub pairing is the most common starting point because it links metrics and traces directly to commits.
The example below shows a typical configuration that connects Datadog, Sentry, and GitHub so Struct can pull metrics, logs, exceptions, and code context into each investigation:
# Datadog + GitHub integration block observability: datadog: api_key: "${DD_API_KEY}" app_key: "${DD_APP_KEY}" regions: ["us1"] query_window_minutes: 30 sentry: auth_token: "${SENTRY_TOKEN}" org_slug: "acme-corp" code_context: github: app_installation_id: "${GH_APP_ID}" repos: - "acme-corp/api-service" - "acme-corp/payments-worker" Trade-off: Broader repo access yields more accurate commit-level attribution but requires a security review. Scope GitHub permissions to read-only on the repositories that own production services.
Connect your observability stack to Struct
Step 3: Ingest and Deduplicate Alerts into Single Incidents
Goal: Prevent alert storms from spawning dozens of redundant investigations for the same underlying failure.
Persona: On-call engineer drowning in duplicate pages.
Inputs: Raw alert stream from Step 1.
Outputs: A deduplicated incident queue where each unique failure maps to exactly one investigation thread.
Alert deduplication groups alerts by service, error fingerprint, and time window. A single database connection-pool exhaustion event might trigger alerts in Datadog, Sentry, and a custom CloudWatch alarm at the same time. Without deduplication, that situation becomes three separate 3 a.m. pages. With deduplication, Struct opens one investigation thread and correlates all three signals into a single timeline.
Trade-off: Aggressive deduplication windows, such as 15 minutes, can hide cascading failures where a second distinct root cause appears shortly after the first. Tune the window per service criticality.
See how Struct tames noisy alert storms
Step 4: Correlate Logs, Traces, and Exceptions into One Timeline
Goal: Replace the manual five-tool context-switching loop with a single, chronologically ordered evidence chain.
Persona: Junior engineer who lacks the tribal knowledge to connect a Sentry exception to a Datadog trace to a GitHub commit manually.
Inputs: Raw logs from CloudWatch, GCP, or Azure, distributed traces from Datadog APM or Grafana Tempo, and exceptions from Sentry.
Outputs: A unified incident timeline with correlated trace IDs, error events, and deployment markers.
Once Struct groups alerts into a single incident, it can correlate every related signal into one view. Struct automatically root-causes engineering alerts by pulling and analyzing metrics, logs, traces, monitors, and code, performing regression analysis and correlating anomalies. The engine matches trace IDs across systems, anchors exceptions to the nearest deployment event in GitHub, and surfaces the earliest anomaly in the chain. That earliest anomaly usually represents the true root cause rather than the noisy symptom that triggered the alert.
Trade-off: Correlation quality drops when trace ID propagation is inconsistent. If services drop trace context at async boundaries, the timeline will contain gaps. Capture those gaps and address them in the post-mortem loop described later.
Watch Struct build a unified incident timeline
Step 5: Encode Tribal Knowledge as Custom Runbooks
Goal: Encode institutional knowledge so the automated investigation follows the same diagnostic path a senior engineer would take.
Persona: Engineering Manager or Staff Engineer who currently holds most of the tribal knowledge.
Inputs: Existing on-call runbooks, correlation ID formats, service-specific escalation paths.
Outputs: Investigations that mirror senior-engineer reasoning and surface service-specific context automatically.
Earlier steps give Struct data and correlation. Custom runbooks add your team’s judgment so investigations feel like a seasoned engineer drove them. Struct’s composable runbook system accepts plain YAML. Paste the runbook into the integration settings and Struct executes it as part of every matching investigation.
The example below shows a payments-worker runbook that queries logs, checks latency, correlates recent commits, inspects downstream services, and then summarizes impact in the right Slack channel:
# Custom runbook - payments-worker high error rate runbook: name: "payments-worker-high-error-rate" trigger: alert_name_contains: "payments_error_rate" steps: - action: query_logs source: datadog query: "service:payments-worker status:error" window_minutes: 15 - action: check_metric metric: "payments.processor.latency_p99" threshold_ms: 2000 - action: correlate_commits repo: "acme-corp/payments-worker" lookback_hours: 2 - action: check_downstream services: ["stripe-webhook-handler", "ledger-service"] - action: summarize include_blast_radius: true notify_channel: "#alerts-payments" Trade-off: Runbooks that are too prescriptive can miss novel failure modes. Include a fallback summarize step that runs even when upstream steps return no data so the investigation always produces an output.
Turn your senior-engineer playbook into executable runbooks
Step 6: Present a Dynamic Dashboard and Root-Cause Summary
Goal: Deliver a single-pane-of-glass view of the incident so the on-call engineer spends minutes reviewing evidence instead of hours hunting for it.
Persona: On-call engineer opening their laptop at 3 a.m.
Inputs: Correlated timeline from Step 4 and runbook outputs from Step 5.
Outputs: A dynamically generated dashboard containing relevant charts, a blast-radius summary, the root-cause hypothesis, and suggested fixes, posted directly in the Slack alert thread.
As Struct co-founder Deepan Mehta states, “Struct gets you from alert → root cause before you even open your laptop.” The dashboard supports that promise by presenting a live, interactive view instead of a static report. Engineers can tag Struct in the thread to pull additional log windows, test alternative hypotheses, or verify whether a specific user was impacted, all inside Slack.
Trade-off: Dashboard fidelity depends on observability coverage. Services with sparse metrics will produce narrower summaries. Treat dashboard gaps as a prioritized backlog for telemetry improvements.
See a sample Struct incident dashboard in action
Step 7: Hand Off to Pull Request or Coding Agent
Goal: Close the loop from alert detection to code resolution without requiring the engineer to rebuild context in a separate tool.
Persona: Engineer who has reviewed the root-cause summary and is ready to implement the fix.
Inputs: Confirmed root cause and suggested fix from Step 6.
Outputs: A GitHub Pull Request or a context-loaded handoff to a coding agent such as Claude Code, with the full incident context pre-populated.
After the engineer confirms the root cause in the Struct dashboard, a single click can initiate PR creation against the identified commit or pass the full investigation context to the configured coding agent. The PR description includes the incident timeline, affected services, and the specific code change rationale. Reviewers receive complete context instead of a blank PR with a vague title.
Trade-off: Automated PR creation works best for well-scoped, single-service fixes. Multi-service refactors still require human architectural judgment. Treat the handoff as a strong starting point, not a final answer.
Explore how Struct hands incidents off to code changes
How Automated Triage Fits Incident Management, Escalation, and Post-Mortems
Automated triage accelerates investigation while existing incident management platforms such as Rootly and PagerDuty continue to orchestrate response. Struct’s output, including root cause, blast radius, and timeline, maps directly onto standard incident fields such as affected services, severity, customer impact, and contributing factors. Post-mortem templates can pull from the Struct dashboard so engineers spend less time reconstructing timelines from memory.
Escalation paths stay the same, which keeps existing on-call processes intact. When Struct’s investigation surfaces a P1 blast radius, the current PagerDuty escalation policy still fires as configured. The difference is that the escalated engineer receives a fully contextualized brief rather than a bare alert string, so they can act faster and with more confidence.
Connect Struct to your existing incident workflow
Measurement Framework: Track MTTR, Escalations, and Triage Time
Teams see the strongest results when they measure the impact of automated triage. Before enabling Struct, record a two-week baseline of three metrics: average triage time per incident from acknowledgment to root-cause identification, MTTR per severity tier, and the number of escalations from junior to senior engineers. Together, these three metrics capture the full cost of manual triage, including investigation time, resolution delay, and senior-engineer load. These numbers form the pre-automation benchmark.
After enabling Struct, review the same metrics weekly for the first month. Triage time usually drops sharply in week one as automated investigations replace manual log-hunting. MTTR often improves in weeks two through four as engineers build trust in the dashboard outputs. Escalation rates tend to fall as junior engineers gain a reliable starting point for every alert.
Use the Struct investigation history to spot recurring alert patterns. Alerts that fire repeatedly with the same root cause signal opportunities for permanent remediation instead of repeated triage. That pattern emerges naturally when every investigation is logged and searchable.
Measure the impact of automated triage on your MTTR
Common Pitfalls and Practical Best Practices
Poor telemetry hygiene. Struct can only investigate with the data your observability tools expose. Services that emit no structured logs, drop trace IDs at async boundaries, or lack basic health metrics will generate incomplete investigations. This happens because Struct cannot correlate events or trace requests across systems without consistent identifiers. The fix is to audit logging coverage before onboarding. Start with the two or three services that generate the most alerts and instrument them to emit structured JSON logs with consistent trace and correlation IDs, then connect them to Struct.
Alert noise overwhelming deduplication. Connecting every Slack channel on day one without tuning severity filters creates an investigation queue that feels unmanageable. Struct still deduplicates, but the volume makes prioritization hard. The fix is to onboard P1 and P2 channels first, set a deduplication window that matches each service’s failure patterns, and expand to lower-severity channels only after the high-severity queue remains stable.
Tribal-knowledge bottlenecks in runbooks. Struct cannot encode runbooks that only exist in people’s heads because the system can only automate diagnostic steps it has been taught. This situation creates a bottleneck where teams that rely on a single senior engineer’s mental model see generic investigations until that knowledge is written down. The fix is to schedule a one-hour runbook-writing session with the senior engineer who handles the most escalations and convert their verbal diagnostic steps into the YAML format shown in Step 5. Even a partial runbook covering the top five alert types significantly improves investigation quality for junior engineers.
Avoid common pitfalls when rolling out Struct
Conclusion: Put Automated Incident Triage into Practice
The seven-step automated incident triage workflow covers the full investigation lifecycle: connect alert sources, map observability and code integrations, ingest and deduplicate alerts, auto-correlate logs, traces, and exceptions, enrich with custom runbooks, generate a dynamic dashboard and root-cause summary, and hand off to PR or coding agent. Struct executes this entire workflow automatically, delivering the triage-time reduction described earlier while maintaining a setup time under ten minutes.
Engineering teams that automate triage reclaim senior-engineer hours currently spent on 3 a.m. log-hunting, reduce MTTR to protect SLAs, and create an onboarding path that lets junior engineers take on-call shifts with confidence. The measurement framework in this article provides the baseline and weekly review cadence needed to track and sustain those gains.
Two adjacent topics worth exploring next are zero-toil alert hygiene programs that reduce raw alert volume before it reaches the triage layer, and post-mortem processes that feed findings back into runbook improvements for continuous MTTR reduction.
Get a live walkthrough of Struct’s automated triage workflow
Frequently Asked Questions
How long does it take to set up automated incident triage with Struct?
Setup typically matches the five to ten minute deployment described earlier. The process involves three authentication steps: connecting your alert source such as Slack channels or PagerDuty, your code repository such as GitHub, and your observability context such as Datadog, AWS CloudWatch, or GCP logs. Once those three connections are authenticated, auto-investigations activate immediately. There is no lengthy enterprise deployment, no professional services engagement, and no weeks-long indexing process. The first automated investigation runs the next time an alert fires in a connected channel.
Is Struct secure enough for companies handling sensitive financial or health data?
Struct is fully SOC 2 and HIPAA compliant. Logs and telemetry data are accessed and processed ephemerally, and Struct does not store them persistently beyond the scope of the active investigation. For most Seed-to-Series-C companies operating under standard compliance requirements, this architecture passes security review. The main scenario where Struct is not currently a fit is an organization with a strict policy that forbids any data from leaving an internal VPC, which would require a fully on-premise deployment that Struct does not yet support at the standard tier.
What happens if our logging and observability setup is incomplete?
Struct produces investigation quality proportional to the telemetry available. If a service emits no structured logs, lacks distributed trace IDs, or has no alerting triggers configured, the automated investigation will be limited to the data that exists. The recommended approach is to start with the services that are already well-instrumented, usually the ones generating the most alerts, and then use gaps in early Struct investigations as a prioritized list of observability improvements. Teams using Sentry for exceptions, Datadog or CloudWatch for metrics and logs, and Slack for alert routing see the highest investigation accuracy from day one.
Can Struct follow our team’s specific diagnostic procedures rather than a generic investigation path?
Struct can follow your exact diagnostic procedures through its composable runbook system, which accepts custom instructions in YAML format. Teams can encode specific log queries, metric thresholds, downstream service checks, correlation ID formats, and escalation paths, and Struct executes those steps automatically for every matching alert type. This approach gives a new engineer on their first on-call shift the same investigation quality as a senior engineer who has debugged the service many times. Runbooks can be updated at any time and take effect on the next investigation without any redeployment.
How does Struct differ from using a general-purpose AI assistant like ChatGPT or Claude for incident triage?
General-purpose AI assistants are reactive, which means the engineer must wake up, manually pull logs from each tool, paste them into the chat interface, and guide the model through each diagnostic step while managing context limits and formatting issues. Struct is proactive and starts investigating the moment an alert fires. It queries all connected data sources automatically, handles large and malformed telemetry natively, and delivers the complete root-cause summary described earlier before the engineer opens their laptop. This proactive behavior matters most at 3 a.m., when cognitive load is highest and investigation speed directly affects SLA performance.
