For Developers
You chose SES for a reason. SendOps makes sure you don't regret it.
SES gives you the cheapest, most reliable email delivery on the market. But everything around it — observability, template management, infrastructure provisioning — is either missing, locked behind CloudWatch, or something you built yourself at 2am. SendOps fills those gaps without changing how you send email.
Everything you'd build yourself, already built
You've probably already written some of this: a script that deploys templates, a Lambda that processes bounce events, a Slack bot that alerts on complaint spikes. It works, mostly — until someone else needs to maintain it, or you need it to do something it wasn't designed for.
SendOps replaces the homegrown plumbing. Observability, templates, alerting, infrastructure management — all built specifically for SES, all accessible through a dashboard your whole team can use, and none of it requires changing a single line in your application.
Your code stays the same
Zero changes to your sending path
Your application sends via SES the same way it does today. Same API calls, same SMTP, same SDK. SendOps never sits between your app and SES.
No SDK to install. SendOps connects to SES via EventBridge and CloudFormation — not through your application code.
No new endpoints to call. Your sending code is untouched. SendOps reads events that SES is already producing.
No vendor lock-in. Remove the CloudFormation stack and SendOps disconnects cleanly. Your SES setup keeps running.
What you get
The operational layer SES is missing
Observability without CloudWatch
Real-time delivery metrics, bounce rates, complaint rates — across every domain and configuration set. Search any email by recipient, message ID, or status. See the full event timeline for every message. No CloudWatch dashboards to build, no Athena queries to write.
→ Learn moreGit-based template management
Templates live in your repository. Edit in your IDE, open a pull request, get automatic validation and rendered previews. Merge to main and SendOps deploys to SES. No console edits, no deployment scripts, no aws ses update-template commands.
Infrastructure provisioned by CloudFormation
One CloudFormation template sets up everything: domain identities, configuration sets, tracking domains, EventBridge rules, IAM roles. Review it like any other infrastructure change. Deploy it the same way you deploy everything else.
→ Learn moreAlerting that reaches your tools
Bounce rate crosses 5%? Complaint rate spikes? Sending quota running low? Alerts go to Slack, email, or webhooks. Trigger PagerDuty or OpsGenie via webhook payloads. No CloudWatch alarms to configure.
→ Learn moreA day with SendOps
How it fits into your workflow
Scenario: Updating a transactional template
Edit the template in your IDE.
Open templates/order-confirmation.html in VS Code. Update the shipping section copy. Commit to a feature branch.
Open a pull request.
SendOps validates the template automatically — syntax check, variable verification, rendered preview. Reviewers see exactly what the email will look like.
Merge and deploy.
PR merges to main. SendOps syncs the updated template to SES within 30 seconds. No scripts, no manual steps.
Monitor the rollout.
Open the SendOps dashboard. See delivery rates for the updated template in real time. Filter by the transactional channel to isolate it from other email types.
Something looks off? You'll know.
Bounce rate ticks up? SendOps alerts your Slack channel. Click through to the message search, find the bounced emails, see the full event timeline. Roll back with a Git revert if needed.
Configuration
Git integration works without any config file.
Connect your repository and SendOps picks up your templates automatically — no config file needed. It detects HTML files, validates them on every push, and syncs to SES on merge.
If you want to go further, add a sendops.json to your repo root. It's purely optional metadata — use it to give templates logical names, link them to test data files in your repo, or both. Test data can also be added directly in the dashboard without touching the repo.
path
Repo-relative path to the HTML template. Use this to give a template a logical name that's independent of its filename or location in the repo.
testdata
A directory of JSON files (trailing /) or a single JSON file. Each file becomes a test data profile — used for rendered previews in pull requests, test sends, and variable validation. Profiles can also be created in the dashboard if you'd rather keep test data out of the repo.
{
"templates": {
"welcome": {
"path": "emails/welcome.html",
"testdata": "fixtures/emails/welcome/"
},
"order-confirmation": {
"path": "emails/order-confirmation.html",
"testdata": "fixtures/emails/order-confirmation.json"
},
"password-reset": {
"path": "emails/password-reset.html"
}
}
}{
"name": "Alice Chen",
"company": "Acme Corp",
"action_url": "https://app.acme.com/onboard"
}Common questions from developers
Keep SES. Lose the plumbing.
Free plan available. Two-minute setup. No SDK, no code changes.