AI-Powered SRE Operations with n8n and MCP

At a Glance

Detail	Value
Industry	SaaS
Environment	AWS multi-account, ECS, RDS, New Relic, PagerDuty, Slack
Timeline	6 weeks design and deployment
Key Results	80% reduction in PIR generation effort, systemic problem patterns identified weekly, SREs reallocated to resilience work

The Challenge

The SRE team managed a complex AWS microservice platform spanning multiple accounts and regions. Every incident followed the same draining pattern:

1. PagerDuty alerted the on-call engineer.
2. The engineer manually gathered telemetry. New Relic dashboards, CloudWatch logs, the AWS Console. Five different tools.
3. Root cause was identified after context-switching across all of them.
4. After resolution, the engineer spent 2 to 4 hours writing a post-incident review (PIR) document.
5. The PIR was filed away in a shared drive, rarely revisited.

The team was processing 15 to 20 incidents per week. PIR writing alone consumed 30 to 60 hours of SRE time weekly. Time that should have been spent addressing the underlying issues the PIRs were meant to identify.

The result was a vicious cycle. Incidents generated PIRs, but there was no capacity to action the findings. The same failure patterns repeated weekly.

The Solution: n8n with MCP Tools

We built an n8n-powered SRE copilot that connected New Relic MCP, CloudWatch MCP, and AWS Core MCP into a single automated pipeline. From incident detection through to a published post-incident review.

Architecture

Three n8n workflows formed the core of the system:

Workflow 1: Incident Triage Bot. Triggered by a PagerDuty webhook. The workflow launched a parallel data-gathering phase:

• Called the New Relic MCP server to fetch relevant dashboards, NRQL query results, and anomaly timelines around the incident window.
• Called the CloudWatch MCP server to pull log groups, error rate spikes, and metric anomalies from the affected services.
• Called the AWS Core MCP server to retrieve the deployment history, task definition changes, and infrastructure events in the window leading up to the incident.

All three MCP calls ran in parallel. The combined output was fed to an LLM node that synthesised a root-cause summary and posted it to the incident Slack channel within 60 seconds of the PagerDuty alert.

Workflow 2: Automated PIR Generation: Triggered when the incident was resolved (PagerDuty resolved webhook). The workflow:

1. Retrieved the full incident timeline from PagerDuty (ack time, response time, resolution time, all notes).
2. Pulled the triage summary and all MCP tool outputs from the original incident run.
3. Queried New Relic and CloudWatch for the post-incident baseline to confirm the system had recovered.
4. Passed everything to an LLM node with a structured PIR prompt that generated an executive summary, timeline of events, root cause analysis, blameless language check, and action items grouped by system area.

The generated PIR was posted to a dedicated Slack channel for review. After a 24-hour review window, a follow-up workflow published it to the team’s documentation site.

Workflow 3: Retrospective Pattern Analysis: Run weekly. The workflow collected all PIRs from the past 7 days, passed them to an LLM node, and generated a cross-incident pattern report:

• Recurring failure modes (e.g. “database connection pool exhaustion in service X”).
• Services with disproportionate incident counts.
• Action items that appeared in multiple PIRs but weren’t addressed.
• Recommendations ranked by potential blast radius reduction.

MCP Integration Details

Each MCP server was wrapped in a lightweight n8n sub-workflow that handled authentication, rate limiting, and error retry. This kept the main workflows clean.

• New Relic MCP: Used to query NRQL for error rates, Apdex scores, and custom dashboard data. The MCP tool interface meant the LLM node could request specific telemetry without hard-coded queries.
• CloudWatch MCP: Used to pull Logs Insights queries, metric alarms, and composite alarm state changes. Critical for understanding what AWS infrastructure observed during the incident.
• AWS Core MCP: Used to describe ECS task definition revisions, RDS event subscriptions, and CloudTrail events. Connected infrastructure changes to incident causation.

The Results

• 80% reduction in PIR generation effort (2 to 4 hours down to 30 minutes of review and editing).
• 60-second incident triage summary, down from 15 to 20 minutes of manual tool-switching.
• Weekly systemic pattern reports that caught recurring failure modes.
• SREs reallocated from PIR writing to postmortem action items, actually improving resilience.
• Consistent PIR quality: every review followed the same structure with blameless language enforced by the prompt.
• Auditable insight: every PIR linked back to the raw MCP tool outputs, so conclusions could be verified.

Key Takeaways

1. MCP turns tools into composable primitives. New Relic, CloudWatch, and AWS each have their own API surfaces, auth models, and query languages. MCP unified them into a consistent tool interface that n8n could call interchangeably. The LLM node didn’t care which MCP server answered the request.
2. Post-incident reviews shouldn’t be written by hand. The facts are already in the tools (PagerDuty timelines, telemetry queries, deployment logs). A structured LLM prompt produces a better first draft than a tired engineer at 2 AM. And the engineer’s review time is spent on insight, not formatting.
3. Cross-incident pattern analysis is the real value. Individual PIRs are necessary but insufficient for systemic improvement. Weekly retrospective analysis that connects dots across incidents is what drives real resilience gains.
4. Free SREs to improve resilience. Every hour spent writing a PIR is an hour not spent fixing the conditions that caused the incident. Automate the documentation so engineers can focus on the engineering.
5. Auditability is non-negotiable. A PIR generated by an LLM is only useful if its conclusions can be traced back to evidence. Every MCP tool call and its response was captured in the workflow state. The PIR always included citations to the raw telemetry data.