All 14 components across 7 PoPs are operating normally.
This is the live operational view of OS Domains email infrastructure. Component health refreshes daily; per-PoP load and queue metrics reflect the day's representative sample. Incidents are classified by severity, posted in plain English with a root-cause analysis appended within 48 hours, and never edited after publication. We host this page outside our primary infrastructure on a separate provider so it stays up if our own network has a problem.
- Avg uptime
- —
- Messages 24h
- —
- Incident-free
- — days
- p99 inbox time
- —
- Active PoPs
- —
- Open incidents
- 0
14 components · 90 days of history
Per-PoP load, queue and latency
Each row reflects the day's representative sample from the PoP itself. Load is the MTA worker pool utilization. Queue is the count of messages being processed or retried. p99 inbox time measures the 99th percentile from API submission to recipient mailbox delivery, averaged across the eight major mailbox providers.
| PoP | Location | Datacenter | IPv4 /24 | Load | Queue depth | p99 latency | Uptime 30d | Status |
|---|
Recent incidents
Every incident gets a root-cause analysis posted within 48 hours of resolution. We don't redact details, we don't soften the language, and we don't quietly remove entries after the fact. If you spot a contradiction between what's posted here and what your monitoring saw, email [email protected] — we want to correct the record.
Upcoming maintenance windows
We announce maintenance windows on this page two weeks before the change. Windows are listed in UTC because daylight-saving boundaries create confusion. If a window affects your specific deployment, you'll get a targeted notification on top of the public announcement.
The probes and definitions behind every number on this page
Uptime calculation
Uptime is the fraction of 30-second monitoring windows during which a component returned an expected response. A component is marked operational if >99.5% of windows succeeded, degraded between 95–99.5%, partial outage between 50–95%, and major outage below 50%. We never round up; an uptime of 99.987% appears as 99.987%, not "99.99%". The monitoring is external — Datadog synthetics from three regions plus our internal probes.
p99 inbox time
We send a synthetic test message every 60 seconds from each PoP to a seeded inbox at each of the eight major mailbox providers. The clock starts at API submission and stops when an IMAP poll confirms the message landed in the inbox folder (not just the MX). p99 is the 99th percentile of those measurements over the rolling 1-hour window. This is not just queue-dispatch time — it's end-to-end including provider processing.
Queue depth
The count of messages currently being processed plus those awaiting retry on each MTA node, aggregated per PoP. Healthy queue depths sit between 0–200 messages depending on PoP volume. Queue depth above 1,000 triggers an internal pager (not necessarily a customer-visible incident; deferrals from one provider can briefly stack up).
Why this page is hosted elsewhere
The status page itself lives on a separate provider (Cloudflare Pages) outside our primary infrastructure. If our datacenter has a problem, you can still see this page. The same applies to the underlying status data — it's pushed from our probes to an independent store, and the page reads from that store directly without touching our customer-facing systems.
If you operate critical email, this is what you should expect to see.
Public status pages are not marketing — they are an operational contract. If your current provider hides incidents, posts vague RCAs, or doesn't expose per-component health, that gap will become your problem during your next outage. Talk to us about migrating to infrastructure that documents itself.