A public deliverability report, starting next month

Most providers talk about deliverability in the abstract. We'd rather publish the actual numbers, on a schedule, and let them speak for themselves. This post is the commitment: what the monthly report will contain and where the numbers come from. It isn't the report itself. We don't have a full calendar month of production traffic yet, and we're not filling that gap with estimates.

What gets published, every month

• Bounce rate and complaint rate, in aggregate across the shared sending pool
• Median and p95 time from accepted to delivered
• Any SES reputation events that affected sending (throttling, pauses) and how long they lasted
• A plain-language note on anything that went wrong, and what changed as a result

Where the numbers come from

Every figure is pulled directly from the same event pipeline that feeds your own dashboard and webhooks (see the data-flow diagram on the GDPR page): SES delivery events ingested into Postgres, aggregated for the calendar month, no manual adjustment. If a number looks bad, it gets published anyway.

Why aggregate across the shared pool specifically

For customers on the shared IP pool (the default for most tiers), your own deliverability is partly a function of everyone else sharing that pool's collective reputation, so the aggregate number is the one that actually predicts what you'll experience. Per-account numbers are available in your own dashboard already; the public report is specifically about the shared infrastructure, since that's the part individual customers can't see or verify themselves without an outside report like this one.

What counts as "something went wrong"

A throttling event from SES, a blocklist listing on a shared IP that got resolved, a bounce-rate spike traced to a specific cause, any of these get a plain-language explanation in the month they happened, not smoothed over in an aggregate number with no context. The goal is a report someone could actually use to decide whether to trust the infrastructure, not a vanity metric with the bad parts filtered out.

How this compares to what most providers publish

Most transactional email providers either publish nothing beyond marketing claims ("industry-leading deliverability") or a status page that only covers uptime, not the deliverability metrics that actually determine whether email reaches an inbox. A status page tells you if the API was up; it doesn't tell you if messages were landing in spam that week. This report is specifically trying to fill that second, more useful gap.

Why there's no report yet

A single day or week of data is noisy and easy to cherry-pick. The first report publishes once a full calendar month of real sending volume exists to summarize. Until then, this page is the commitment, not the content.