Sessy

Marc Köhlbrugge built Sessy to eliminate the operational opacity of troubleshooting Amazon SES email delivery through raw AWS CloudWatch logs and scattered SNS configurations. Instead of paying recurring monthly markups for third-party email wrappers just to view message delivery states, he engineered an open-source observability dashboard tailored directly to SES event streams. The project gives infrastructure operators complete visibility into transactional email lifecycles alongside an AI-ready Model Context Protocol interface, without altering outbound sending pipelines.

Why Sessy instead of Resend

Resend operates as a managed platform combining developer APIs with delivery analytics and React Email tooling. Adopting Resend requires routing outbound traffic through third-party infrastructure, managing an extra API key, and accepting tiered subscription costs as email volume scales. For teams already operating in AWS, an external intermediary introduces separate vendor agreements and egress dependencies.

Sessy keeps the operational footprint focused strictly on observability. Application services continue sending mail directly through Amazon SES via existing SMTP or AWS SDK credentials. Sessy sits out-of-band as a lightweight Docker container, ingesting delivery, bounce, complaint, open, and click events published asynchronously by Amazon SNS. Engineering teams retain recipient data within their own network perimeter, store event history in local SQLite or PostgreSQL, and avoid per-message platform charges.

What it does well

• Webhook-driven event ingestion captures Amazon SES lifecycle events—including deliveries, bounces, complaints, delays, rejections, opens, and clicks—via Amazon SNS without requiring AWS IAM access keys.
• Built-in Model Context Protocol (MCP) server exposes a read-only endpoint for AI assistants like Claude Code and Cursor to query delivery timelines and diagnostic codes directly from the editor.
• Searchable message timeline correlates recipient addresses, SES message IDs, subject lines, and raw SMTP response codes for fast bounce triage.
• Compact deployment footprint runs on Ruby on Rails with SQLite on a persistent volume, with optional PostgreSQL for higher message throughput.
• Embedded Solid Queue interface at /jobs lets operators inspect webhook background processing, monitor worker queues, and retry failed job runs.