The green dashboard, and the number it quietly leaves out

What a status page can honestly tell you, and what it can't

Every infrastructure provider has a status page, and most of them are quietly misleading. They show a wall of green and a number like 99.99%, and they invite you to conclude that the service is reliable. The number is usually real. The conclusion often isn't, because for email specifically there are two completely different things being measured, and the green dashboard only covers one of them. This page explains both, tells you what we actually commit to, and points you at the live data rather than asking you to trust a marketing figure.

The first thing being measured is infrastructure availability: are the SMTP endpoints accepting connections, is the API responding, are the dashboards reachable. That is the thing a status page is good at showing, and it's the thing we report. The second thing — the one that actually determines whether your email does its job — is whether the messages land in the inbox. No status page in this industry shows that honestly, because it's harder to measure, it varies by recipient domain, and a lot of it depends on factors the provider doesn't fully control. We'd rather be straight about the distinction than let a green dashboard imply a promise we can't keep.

The uptime number, and how we calculate it

We report availability on a rolling 90-day window, not a monthly reset. This matters more than it sounds. A monthly figure resets the counter on the first of each month, which means a provider can have a genuinely bad week, wait for the calendar to turn over, and show you a fresh 100% a few days later. The rolling window doesn't let anyone hide that way — a bad incident stays visible in the number for a full quarter. If you're evaluating reliability, a rolling 90-day figure is the honest one to ask any provider for, and the one to be suspicious about when it's missing.

The components we track separately are the ones that fail independently: SMTP relay ingestion, the Email API, outbound delivery from the dedicated IP pools, the DNS and authentication services, the customer dashboards, and the billing portal. Tracking them separately matters because "the service" is rarely all-or-nothing. The API can be degraded while SMTP is fine. Outbound delivery can slow on one IP range while everything else is healthy. A single aggregate number hides exactly the detail an operations team needs during an incident, so we don't aggregate it away.

What we commit to, stated as targets rather than fine print

Our availability target for the core sending path — SMTP relay and Email API ingestion — is 99.95%. In a 90-day window that allows for roughly three hours of cumulative unavailability before the target is missed. We state this as a target rather than burying a contractual guarantee in a service agreement, and the distinction is deliberate. A target we publish and report against honestly is more useful to most customers than a guarantee whose credit terms refund a token fraction of the monthly bill. The large cloud providers learned this the expensive way: across one recent twelve-month period the three biggest accumulated over a hundred service outages between them, all nominally covered by SLAs, with credits that amounted to pennies against the actual cost of the downtime to their customers.

For customers who need a contractual SLA with defined credits — common in regulated procurement, and a real requirement under some financial-sector vendor frameworks — that's available on the dedicated and Custom tiers, written into the agreement with specific measurement methodology and credit schedules. The point of the public target is transparency for everyone; the point of the contractual SLA is recourse for those whose compliance obligations require it. They serve different purposes and we keep them separate rather than pretending the public number is a legal commitment.

The part the green dashboard doesn't show: inbox placement

Here's the uncomfortable truth that distinguishes email from almost any other infrastructure. You can have 100% uptime, 100% of messages accepted and delivered to the receiving server, and still have a meaningful fraction of them land in spam. Delivery and inbox placement are different measurements. Delivery means the receiving mail server accepted the message. Placement means it reached the inbox rather than the junk folder. The gap between them is where email programs quietly fail, and it's invisible on a conventional status page.

The 2026 benchmarks make the scale of this concrete. Median inbox placement across industries ranges from around 86% at the low end to roughly 92% for B2B senders with disciplined programs. That six-point spread is not about server uptime — every provider in that data had excellent uptime. It's about sender reputation, authentication posture, list hygiene and sending discipline. A provider that shows you 99.99% availability and stays silent about placement is showing you the easy number and hiding the one that determines whether your billing emails and password resets actually arrive.

We can't put inbox placement on a real-time dashboard honestly, because it depends on the recipient domain, your sending behaviour, and reputation signals that accumulate over weeks. What we can do is be transparent that it's the metric that matters, monitor it for managed customers through seed-list testing and the aggregate DMARC reports we process, and treat a placement decline as the operational incident it actually is — not wait for the SMTP endpoint to go red before we act.

How incidents appear here, and the language we use

When something does go wrong, the incident moves through four states, and we use the same vocabulary the rest of the industry has settled on so there's no ambiguity. Investigating means we've confirmed a problem and are diagnosing it. Identified means we know the cause and are working on the fix. Monitoring means the fix is deployed and we're watching to confirm it held. Resolved means it's over and we're confident it won't immediately recur. Each state change carries a timestamped update, and we hold to a fixed update cadence during an active incident rather than going silent — the silence between updates is what erodes trust faster than the incident itself.

The incidents we treat as reportable go beyond the obvious endpoint-down case. A blocklisting event on a shared range, a sustained delivery slowdown, a DNS or authentication problem affecting a subset of customers, a dashboard outage — these all get posted, because from a customer's side a delivery slowdown they can't see explained is just as alarming as a hard outage. For incidents that touch personal data, the status timeline runs in parallel with the formal breach-notification process described in the Data Processing Agreement, which carries the regulatory 72-hour clock under GDPR.

Past incidents stay visible

The incident history doesn't get quietly pruned once things are resolved. Past incidents remain on the timeline with their full update trail and, where useful, a short post-incident note on what caused it and what changed afterward. This is partly accountability and partly something more practical: a provider's incident history is one of the few honest signals you have about how it actually operates. A page showing a handful of incidents over years, each resolved quickly with a clear explanation, tells you more about reliability than any uptime percentage. A page with no history at all usually means the page is new, not that the provider is flawless.

Maintenance, and why we schedule it the way we do

Planned maintenance is announced in advance on the status dashboard, scheduled into the lowest-traffic windows for the regions affected, and structured so the sending path stays available even while a dashboard or a secondary service is being worked on. Email infrastructure has a useful property here: outbound mail can queue. A brief maintenance window on a non-critical component rarely means lost mail, because the queue absorbs it and delivery resumes when the component is back. We still announce it, because a customer watching their own dashboards deserves to know why a number moved, even when nothing was actually at risk.

What this page is, in one honest sentence

It's a description of infrastructure availability that we report transparently on a rolling window, paired with an open admission that the metric most providers hide — whether your email reaches the inbox — is the one that actually matters, and the one we'd rather discuss with you directly than reduce to a misleading dot of green. Reliability in this business isn't a number on a dashboard. It's 23 years of the same team keeping the queue moving, and an incident history short enough to read in a few minutes.