# Connect AWS CloudWatch to PagerDuty > Turn CloudWatch alarms into PagerDuty incidents instantly, so your on-call team is always the first to know. **Canonical page:** https://tray.ai/connectors/aws-cloudwatch-pagerduty-integrations/ **AWS CloudWatch connector:** https://tray.ai/connectors/aws-cloudwatch-integrations/ **AWS CloudWatch documentation:** https://tray.ai/documentation/connectors/service/aws-cloudwatch ## Overview AWS CloudWatch and PagerDuty do two different jobs that only work when they're connected. CloudWatch watches your AWS infrastructure continuously, tracking metrics, logs, and alarms across EC2, Lambda, RDS, and dozens of other services. PagerDuty makes sure the right engineers are notified and moving the moment something breaks. Without a connection between them, there's a gap between detection and response where incidents go unnoticed and resolution time climbs. Connecting these platforms through tray.ai closes that gap — an automated pipeline from anomaly to alert to fix. CloudWatch alarms firing in isolation create noise without action. Engineers miss threshold breaches, teams rely on manual checks to translate infrastructure warnings into support tickets, and MTTR suffers. Connecting AWS CloudWatch to PagerDuty through tray.ai lets operations teams automatically create, route, and escalate incidents based on real-time AWS signals. You get full control over which alarms trigger which PagerDuty services and escalation policies. High-severity production outages wake the right on-call engineer within seconds, while low-priority warnings are logged without unnecessary interruptions. Faster incident response, less alert fatigue, and your AWS environment actually talking to your incident management workflows. ## Use cases ### CloudWatch Alarm to PagerDuty Incident Creation When a CloudWatch alarm transitions to ALARM state — whether from high CPU utilization, memory pressure, or network anomalies — tray.ai opens a new PagerDuty incident and routes it to the appropriate service and escalation policy. The incident is populated with alarm metadata including the affected resource, metric value, and breached threshold, giving on-call engineers immediate context without needing to log into the AWS console. - No manual effort to translate CloudWatch alarms into PagerDuty incidents - On-call engineers are notified within seconds of threshold breaches - Incidents include AWS context for faster triage and diagnosis ### Auto-Resolve PagerDuty Incidents When CloudWatch Returns to OK When a CloudWatch alarm recovers and transitions back to OK state, tray.ai automatically resolves the corresponding PagerDuty incident. Stale alerts stop cluttering dashboards and keeping engineers unnecessarily on edge. PagerDuty always reflects the true health of your AWS infrastructure in real time. - Eliminates stale incidents that distract on-call teams - Keeps PagerDuty dashboards accurate - Reduces unnecessary escalations and on-call fatigue ### Severity-Based Incident Routing from CloudWatch Metrics A Lambda timeout deserves a different response than a full RDS database failure. With tray.ai, you can define conditional logic that maps CloudWatch alarm severity, namespace, or resource type to specific PagerDuty services, urgency levels, and escalation policies. Critical P1 incidents immediately page senior engineers while informational warnings are quietly logged for review. - Right-sized responses for alarms of different severity levels - Reduces alert noise by routing low-priority alarms to non-urgent channels - Improves on-call experience with context-aware escalation policies ### CloudWatch Log Insights Anomaly Alerting via PagerDuty CloudWatch Log Insights can surface error spikes, unusual patterns, and application-level failures buried in log streams. By connecting with PagerDuty through tray.ai, teams can trigger incidents when log-based metric filters breach thresholds — a sudden surge in 5xx errors or repeated authentication failures, for example — so application-layer issues get the same incident management treatment as infrastructure alarms. - Extends incident coverage from infrastructure to application-level log anomalies - Enables log-driven alerting without building custom notification pipelines - Catches error patterns early before they become customer-facing outages ### Scheduled AWS Health and Budget Alarm Summaries to PagerDuty Beyond real-time alerting, tray.ai can run scheduled workflows that query CloudWatch for metric trends, billing anomalies, or AWS Health events and push summarized reports as low-urgency PagerDuty incidents or status updates. Operations teams get visibility into slow-burning issues — gradually increasing error rates, cost overruns — before they hit critical thresholds. - Surfaces gradual degradation before it becomes a crisis - Keeps teams informed about AWS cost and health without manual reporting - Reduces surprise incidents through trend-aware monitoring ### Multi-Region CloudWatch Alarm Aggregation into Unified PagerDuty Incidents Organizations running workloads across multiple AWS regions often end up with the same underlying issue triggering dozens of redundant alarms. tray.ai can aggregate correlated CloudWatch alarms from multiple regions into a single, deduplicated PagerDuty incident, cutting the noise and helping on-call engineers find the root cause without sifting through hundreds of duplicate notifications. - Dramatically reduces incident noise from correlated multi-region alarms - Engineers see one consolidated incident rather than dozens of duplicates - Accelerates root cause identification by surfacing the full blast radius ### Post-Incident CloudWatch Metric Snapshots Attached to PagerDuty Once a PagerDuty incident is resolved, tray.ai can automatically retrieve historical CloudWatch metric data from the incident window and attach it as notes or links within the PagerDuty incident timeline. Every incident becomes a self-documenting record with the exact metric graphs and log data from the failure period, so post-mortems move faster without engineers manually pulling reports after the fact. - Automatically generates metric evidence for every incident post-mortem - Saves engineering time during incident review cycles - Creates an auditable trail of infrastructure behavior during each incident ## Templates ### CloudWatch Alarm → PagerDuty Incident (Real-Time) Automatically creates a PagerDuty incident whenever a CloudWatch alarm transitions to ALARM state, populating it with the alarm name, affected AWS resource ARN, breached metric value, and a direct link to the CloudWatch console. Resolves the incident automatically when the alarm returns to OK. Connectors used: AWS CloudWatch, PagerDuty ### Severity-Tiered CloudWatch to PagerDuty Routing Evaluates incoming CloudWatch alarms against a configurable severity matrix and routes them to the appropriate PagerDuty service and urgency level. Critical production alarms trigger high-urgency incidents with immediate escalation, while non-critical alarms create low-urgency incidents without waking on-call staff. Connectors used: AWS CloudWatch, PagerDuty ### CloudWatch Log Metric Filter Breach to PagerDuty Alert Monitors CloudWatch log metric filters for application-level anomalies such as error rate spikes or failed authentication events. When a log-based metric breaches a defined threshold, tray.ai triggers a PagerDuty incident with log query context, so application teams can investigate faster. Connectors used: AWS CloudWatch, PagerDuty ### Multi-Region Alarm Deduplication and PagerDuty Consolidation Aggregates CloudWatch alarm events from multiple AWS regions, detects correlated alarms representing the same underlying issue, and creates a single consolidated PagerDuty incident rather than flooding on-call engineers with duplicate notifications. Subsequent correlated alarms are appended as notes on the existing incident. Connectors used: AWS CloudWatch, PagerDuty ### Post-Incident CloudWatch Metric Report Attachment When a PagerDuty incident is resolved, automatically queries CloudWatch for metric statistics covering the incident window and attaches a formatted summary — including peak values, anomaly timestamps, and affected resource identifiers — directly to the PagerDuty incident as a post-mortem data artifact. Connectors used: AWS CloudWatch, PagerDuty ### Daily CloudWatch Anomaly Digest to PagerDuty Open Incidents Runs on a daily schedule to query CloudWatch Anomaly Detector findings and AWS Health events, then creates low-urgency PagerDuty incidents for any new anomalies found. Teams get visibility into gradual degradation without relying solely on threshold-based alarms. Connectors used: AWS CloudWatch, PagerDuty ## Challenges Tray.ai solves ### Alarm State Transitions Generating Duplicate or Redundant Incidents CloudWatch alarms frequently flap between ALARM and OK states during intermittent issues, flooding PagerDuty with duplicate incident create and resolve events that exhaust on-call engineers and erode trust in the alerting system. **How Tray.ai helps:** tray.ai workflows implement deduplication logic using PagerDuty's dedup_key field and state-tracking within the workflow itself, so a flapping alarm maps to a single incident lifecycle rather than generating a flood of redundant notifications. ### Mapping AWS Resource Context to Actionable PagerDuty Incidents Raw CloudWatch alarm payloads contain AWS-specific identifiers like ARNs, metric namespaces, and dimension keys that mean something to AWS engineers but leave on-call responders without the plain-language context they need to act quickly. **How Tray.ai helps:** tray.ai's data transformation tools let teams parse and enrich CloudWatch payloads — translating resource ARNs into human-readable names, appending runbook links, and formatting metric data into clear incident summaries — before anything reaches PagerDuty. ### Routing Alarms from Multiple AWS Accounts and Regions Enterprises running across multiple AWS accounts and regions face a real headache consolidating CloudWatch alarms from fragmented infrastructure into a coherent PagerDuty incident structure without building and maintaining custom routing logic in every account. **How Tray.ai helps:** tray.ai acts as a centralized integration layer that receives alarm events from all AWS accounts and regions via a shared SNS endpoint, applies unified routing logic, and maps alarms to the correct PagerDuty services and teams — no per-account Lambda functions required. ### Keeping PagerDuty Incident State in Sync with CloudWatch Alarm Lifecycle Without automated lifecycle management, PagerDuty incidents stay open long after a CloudWatch alarm has recovered, creating stale incident backlogs that mislead teams about actual infrastructure health and make on-call handoffs messy. **How Tray.ai helps:** tray.ai workflows handle the full alarm lifecycle — creating incidents on ALARM transitions, acknowledging them when engineers accept the alert, and resolving them automatically when CloudWatch returns to OK — so PagerDuty stays synchronized with live AWS infrastructure state. ### Alert Fatigue from High-Volume CloudWatch Metric Alarms Large AWS environments with hundreds of monitored resources can generate enormous volumes of CloudWatch alarms, many representing expected transient conditions. Routing all of them directly to PagerDuty overwhelms on-call teams and causes critical alerts to get buried. **How Tray.ai helps:** tray.ai filters and aggregates before incidents reach PagerDuty — suppressing known transient alarms, grouping related metric failures into single incidents, and applying time-based rules that reduce off-hours notifications for non-critical services — so engineers only see alerts that actually need a human response. ## Learn more - Intelligent Integration: https://tray.ai/platform/intelligent-ipaas/ - Merlin Agent Builder: https://tray.ai/platform/merlin-agent-builder/ - Agent Gateway for MCP: https://tray.ai/platform/agent-gateway/ - Book a demo: https://tray.ai/contact/