AWS SES monitoring: the metrics and alerts that matter

The Gap

SES sends the email. Seeing what happened is your job.

You call SendEmail, SES returns a message ID, and the call looks like a success. Whether that email was delivered, bounced, landed in spam or was never rendered at all is recorded somewhere — but not anywhere your team looks by default. SES has no built-in alerting on your sending health and no dashboard that flags a bounce rate drifting toward the review threshold.

At low volume, an occasional glance at the SES console is enough. Once email carries password resets, onboarding, receipts or revenue, "occasionally" stops being a strategy. The questions start arriving:

• Is our bounce rate trending toward the 5% review threshold?
• Did complaints rise after Tuesday's campaign or template change?
• Are password reset emails being delivered right now?
• Which domain, template or configuration set is causing the problem?
• Can support check a customer's email without AWS console access?

SES exposes the raw ingredients to answer every one of these. Turning them into monitoring means wiring together event publishing, a message bus, processing, storage, dashboards, alarms and IAM — and teams usually start that work after the first incident, not before it. The rest of this guide is about what to watch and how to act on it, whichever way you build it.

Metrics

The AWS SES metrics worth monitoring

SES generates a lot of event data. For monitoring, six signals matter more than the rest — bounces and complaints because SES enforces thresholds on them, the others because they catch problems before those thresholds move.

Bounces deserve the most detail. A hard bounce is a permanent failure — the address doesn't exist — and every repeat send to it counts against you. A soft bounce is temporary: a full mailbox, a server that's briefly unavailable. Keep them apart in your metrics, and make sure hard-bounced addresses stop receiving mail. Our guide to the SES bounce rate covers how AWS calculates it and how to bring a high rate down.

Complaints need context, not just a number. When the complaint rate moves, the useful question is "what changed right before it?" — a new segment, a new subject line, a template edit, a campaign to an older list. Monitoring that can't connect the metric to the change leaves you guessing.

Watch the health of your monitoring, too. If send volume holds steady but delivery events stop arriving, the problem may be your event pipeline rather than your email. A sudden drop to zero is rarely good news.

Beyond the SES events, two infrastructure checks catch problems early: SPF, DKIM and DMARC records that have drifted (a missing DKIM selector after a key rotation fails authentication silently), and your sending domains or dedicated IPs appearing on blocklists. The Amazon SES deliverability guide goes deeper on both.

Segmentation

Monitor by traffic type, or one stream hides another

Password resets, receipts, invitations, lifecycle emails and marketing campaigns carry different risk and different urgency. An account-wide bounce rate of 1.5% can hide a campaign stream running at 6% behind a large volume of clean transactional mail — and SES reviews the account, not the stream.

Separate your traffic with configuration sets — at minimum one for transactional and one for marketing mail — and break your metrics down by:

This is the most common blind spot in homegrown SES monitoring: the events are collected, but not structured in a way that supports diagnosis.

Thresholds

Alert thresholds tied to an action

AWS publishes the rates at which it steps in. Typically, an account is placed under review at a 5% bounce rate or a 0.1% complaint rate, and sending can be paused at around 10% bounces or 0.5% complaints. If your first alert fires at those numbers, you have no room left to react. Set a ladder below them, and attach an action to each rung:

Warning and critical levels are suggestions — tune them to your volume and baseline. The SES review and pause rates are set by AWS.

The thresholds are half of an alerting system. The other half is how the alert behaves:

Runbook

What to do when an alert fires

An alert is only as useful as the response behind it. Write the first steps down before you need them, so whoever is on call doesn't have to improvise.

If AWS has already placed your account under review, the response shifts to fixing the cause and explaining it to AWS — see how to bring a high SES bounce rate down and the sending limits guide for how reputation and quota interact.

Architecture

A baseline monitoring setup on AWS

CloudWatch on its own gets you part of the way. SES publishes account-level reputation metrics — Reputation.BounceRate and Reputation.ComplaintRate — and an alarm on each is the least every production account should have. What it won't give you is a breakdown by configuration set or template, message-level history for support questions, or a view non-engineers can use. For that, most teams end up building the same pipeline:

1. 1 Publish events from configuration sets. Turn on event publishing for sends, deliveries, bounces, complaints, rejects, delivery delays and rendering failures — plus opens and clicks if you track them.
2. 2 Route them to a bus. Amazon EventBridge or SNS as the event destination. Kinesis Data Firehose if you need high-volume delivery to storage.
3. 3 Normalize and enrich. A Lambda function (or stream processor) parses each event type and tags it with configuration set, template and application.
4. 4 Store raw and aggregated data. Raw events in S3 for audit and message-level lookups; aggregates in a database or as custom CloudWatch metrics.
5. 5 Build dashboards. Account-wide and per-segment views of the metrics above, with trends rather than snapshots.
6. 6 Add alarms and routing. Threshold alarms to Slack, PagerDuty or email, routed by stream and owner.
7. 7 Write the runbooks. So the person on call knows what to check first.

This works, and plenty of teams run it well. Budget for what you then own: event schema changes, retention and storage costs, alert tuning, IAM policies, Lambda runtime upgrades, and failure handling in the monitoring pipeline itself. Rename a configuration set and the pipeline can break silently — so the system that tells you whether email works needs its own monitoring. Your email infrastructure now has infrastructure.

Keep it isolated from your sending path, too. If the same Lambda or deployment pipeline handles both sending and event processing, one bad deploy can take out email and your view of it at the same time.

Templates

Template changes are part of monitoring

A complaint spike after a template edit isn't a deliverability mystery; it's a change-management problem. A broken variable reference causes rendering failures for every recipient of a send. New copy can move complaints and engagement within hours.

SES stores templates in your account with no version history and no review step: an edit through the console or API replaces the live version. To connect content changes to metric changes, you need to know which version was live when a message went out. Keeping templates in Git — or any system with version history and review — gives you that: instead of asking "why did complaints rise this week?", you can ask "did the onboarding copy shipped on Tuesday cause it?" Our React Email and Amazon SES guide covers one way to version and deploy SES templates.

Team Access

Make the answers available beyond engineering

If checking whether a customer received their invoice requires a CloudWatch Logs Insights query, most of your team won't do it — they'll ask an engineer. Monitoring that only one or two people can read isn't monitoring; it's an interrupt queue.

Different roles need different answers, quickly:

• Support: was this specific email accepted, delivered or bounced — and why?
• Marketing: how healthy was this campaign, and which segment caused the complaints?
• Engineering: is this an event anomaly, a template bug or a provider issue?
• Operations: are we approaching a threshold, and who needs to act?

That means keeping message-level event history, searchable by recipient, and giving people access to it without handing out AWS console permissions they shouldn't have.

Mistakes

Common SES monitoring mistakes

SendOps

Build it, or use SendOps

Building SES monitoring yourself is a legitimate choice, especially with an infrastructure team and an existing CloudWatch investment. Be honest about the full cost: weeks for the first version, then permanent ownership of a system whose only job is to tell you whether another system works. And the risk is highest in the gap while it's still being built.

SendOps is an email workflow and drip campaign platform built on Amazon SES, and monitoring is part of it. It connects to your AWS account through a scoped IAM role and a CloudFormation stack that routes your SES events to SendOps through EventBridge, and gives you:

Your existing application keeps calling SES directly; nothing in your sending path changes. There's a free plan, and the same events power the workflows and broadcasts you send through SendOps.