Spacemail Is Down: What the August 2026 Outage Teaches About Provider Failures

If you are checking whether Spacemail is down, the official answer at 2026-08-13 20:28 UTC is that Spacemail remains listed in an ongoing Spaceship incident. The official status account says a power outage at its Phoenix datacenter affected Spacemail and several other services. It has reported recovery for some payment paths, but it has not published a Spacemail all-clear or a recovery ETA in the status sequence checked for this article.

Last checked: 2026-08-13 20:28 UTC.

Confirmed by @SpaceshipStatus: the incident is associated with a power outage at the Phoenix datacenter. The affected-service list names Spacemail, EasyWP, Spaceship VPS virtual machines, volumes and load balancers, Email Support, Spaceship Email Forwarding, billing and external payment processing, and websites hosted on Shared servers. Later posts say external confirmation-based payments and BTCPay were restored. Those are payment updates, not a general recovery notice for Spacemail.

If you are affected, follow the official status account and preserve your current DNS, MX, client, and mailbox configuration until the provider publishes recovery guidance.

A provider-wide incident is different from one failed API call. Multiple products, regions, or delivery paths can share a datacenter, control plane, identity service, network edge, or power and cooling domain. A dependency diagram may show several boxes while the physical failure domain underneath them is still one box.

The motivating incident is a prompt to ask a broader question: which application features fail together when one external location or provider control plane is unavailable? The answer is not visible in a vendor count. It comes from mapping routes, credentials, DNS, queues, callbacks, administration paths, and recovery controls to their real failure domains.

This is an engineering inference and general reliability lesson, not a claim about Spaceship’s internal design.

A provider outage, bad DNS answer, expired credential, blocked egress path, and application regression can all surface as timeouts or connection failures. They demand different fixes.

Start with independent evidence. Compare the provider’s official status with synthetic checks from more than one network or region. Resolve the hostname through authoritative and recursive DNS. Test the protocol endpoint without the application. Compare multiple tenants or accounts. Check recent deploys and configuration changes. A broad provider-side pattern should be reproducible outside one application and align with provider evidence; an app-specific failure usually stops at a narrower boundary.

Blast-radius mapping is not a list of products from a status page. It is a map from affected dependency capabilities to your user journeys. For an email dependency, inbound mail, outbound mail, mailbox access, authentication messages, support replies, billing notices, and administrative recovery may have different paths even when they share one provider name.

Mark each journey as unavailable, degraded, delayed, or unaffected. Then identify which paths are reversible. Delaying a notification can be safe when its intent is durable; routing authentication mail incorrectly or duplicating a billing message may be worse than pausing it. This keeps the team from applying one global failover switch to workflows with different correctness requirements.

For each user journey, record the data path, control path, and recovery path. Ask whether operators can still change routing when the provider dashboard, identity system, or support channel is affected. Ask whether health signals are generated outside the failed region. Ask where queued work and durable state live. A recovery control that depends on the failed domain is not an independent recovery control.

Teams often configure a secondary region and assume they now have high availability. The real system includes health evaluation, routing policy, credentials, network allowlists, replicated configuration, state consistency, and the decision process that moves traffic. If any one of those still pins requests to the unhealthy primary, the secondary is capacity, not failover.

Routing policy should be explicit and testable: prefer the healthy primary, use the healthy secondary when the primary is ineligible, and fail closed when neither route is safe. Do not spread retry attempts across unhealthy targets without a budget. A stale health signal can cause flapping; an over-broad catch can send the same side effect twice. The failover unit therefore needs bounded decisions, stable operation identity, and observable route selection.

Failover is not always the safest response. A secondary provider or region adds configuration drift, data residency, deliverability, suppression-list, template, credential, and duplicate-operation risks. Some systems should queue work durably and show a delayed state; others need an alternate channel; still others should stop rather than risk an incorrect or duplicate action.

Define the degraded-mode contract before the incident. State what remains available, what is delayed, how long work can queue, what users will see, and which operator can escalate to failover. For critical access flows, build a recovery path that does not depend on the same provider and control plane. For non-critical notifications, preserve intent and expose queue age instead of pretending delivery succeeded.

Buglyst’s provider-outage playbook turns this article into an operational sequence: distinguish provider failure from app or DNS failure, map blast radius, inspect health and routing, select a degraded mode, and prove recovery. It is designed to remain useful after this incident is resolved.

The playbook links to a fictional JavaScript lab where the primary region is known unhealthy, a healthy secondary exists, and delivery still goes to the primary because the route selector ignores health. The exercise is deliberately narrow: find the routing bug, make the smallest defensible correction, and pass visible and hidden checks without learning anything about a real provider’s internals.