System status

What this page is for

This page answers one question: is PXCMail working right now, and if not, what are we doing about it? Each row above is a part of the service that your office touches. A green “Operational” pill means our monitor can complete that function end to end. Anything else is explained in an incident entry below the table, with a timeline that updates until the incident is resolved. The 90-day uptime column stays blank until the monitor has 90 days of data; we do not publish numbers we have not measured.

What each component means

• Mail ingress (Gateway relay, MX). Our servers accepting mail from the internet and from your Google Workspace or Microsoft 365 tenant. If this is down, senders’ servers queue and retry; no mail is lost, it is late.
• Outbound delivery. Mail leaving PXCMail for the internet after the policy decision. A problem here shows up as delayed delivery, not bounces.
• Encrypted delivery pages. The reading pages where a recipient enters a one-time code to open a locked message. If these are down, recipients can see the notification but cannot open the message until the pages return.
• Hosted mailboxes (IMAP/EWS/ActiveSync). Mailbox sync for Outlook, iPhone and Android on Hosted plans. Gateway customers are not affected by this row.
• Webmail. The browser mailbox for Hosted plans.
• Admin console & audit exports. The console, policy editor, archive search and export jobs. Mail keeps flowing under the last saved policy even if the console is unavailable.

How we monitor

The monitor runs in a separate account from production, with its own credentials and its own hosting, so it keeps reporting when production cannot. It performs the same actions your staff do: an SMTP connection and TLS handshake to the MX, a round-trip test message through a canary organization, a sign-in to a test mailbox over IMAP, EWS and ActiveSync, a page load of the locked-delivery reading page, and a console sign-in followed by a small audit export. Checks run from more than one US location, and a component is marked degraded only when checks fail from more than one location, so a monitor problem is not reported as a service problem. The SLA uses this monitor as its source of truth.

How incidents are communicated

Every incident entry moves through four states, each stamped with a Pacific time:

1. Acknowledged. We have confirmed a problem and named the affected components. For a P1 (a component unavailable to all users) this happens within 30 minutes of detection, and usually sooner.
2. Identified. We know the cause and a fix is in progress. Updates continue at least every 15 minutes during a P1, even when the update is “still working on it”.
3. Monitoring. The fix is in place and we are watching for recurrence.
4. Resolved. The component has been stable; the entry closes with a short summary.

Any incident over 30 minutes gets a written post-incident review on this page: timeline, impact, root cause and corrective actions, in the format of the sample incident. Customers whose organization was affected also get an email and a console banner, as described on the incident response page. Email and RSS subscriptions open at launch; until then, this page is the record.

How this maps to the SLA

The Service Level Agreement targets 99.9% monthly availability on every plan, measured by this monitor. Downtime starts after five consecutive minutes of a covered component being unavailable to all of your users. On Hosted Pro the target is contractual: if a month closes below 99.9%, service credits of 10% to 50% of that month’s Hosted Pro fees apply to a future invoice. To claim, email support within 30 days after the month ends with the dates and times you observed; we confirm them against the monitor within 15 days. Scheduled maintenance, announced at least 72 hours ahead and limited to 4 hours a month between 10 pm and 4 am Pacific, does not count as downtime.

Example

At 9:40 am the front desk at Lakeside Family Dental notices that a pre-authorization sent to an insurer at 9:10 has not been opened. The office manager checks this page before calling support. Outbound delivery shows “Degraded”, with an entry acknowledged at 9:22 and identified at 9:35: a queue backlog, messages delayed but not lost. She tells the front desk to wait rather than resend, which would have produced duplicates. The entry resolves at 10:05, and because the incident ran longer than 30 minutes, a post-incident review appears on this page within ten business days.

FAQ

Why is the 90-day uptime column blank?

Because the monitor has not been running for 90 days. The column fills in from measured data; we do not backfill or estimate.

Does a status incident mean my data was exposed?

No. This page reports availability. Security incidents are handled under the incident response process and communicated to affected customers directly, within 72 hours of determination.

Should I change my DNS during an outage?

Not unless an incident entry tells you to. Repointing MX or sending records bypasses the policy engine and the archive, and senders’ servers already retry for 24 to 72 hours.

I am on Gateway. Which rows matter to me?

Mail ingress, outbound delivery, encrypted delivery pages and the console. The mailbox and webmail rows apply only to Hosted plans.

Contact

If you see a problem this page does not show, report it in Console → Support or email [email protected]. Outages are answered 24/7.