Is DNSimple down right now?

While you wait: the DNSimple incident checklist

1. Name the dependency precisely. DNSimple is your edge delivery, DNS or traffic-security dependency. Identify which of these surfaces is actually in the production path: DNS resolution, TLS, caching, request filtering, routing and origin reachability.
2. Confirm the affected path. Use DNSimple's component and incident detail, then probe from more than one network and region, then compare DNS, TLS, edge and origin behavior as separate layers.
3. Bound every retry. Cap concurrency, use exponential backoff and retain idempotency where applicable. An upstream incident should not become a retry storm against DNSimple or your own services.
4. Use the rehearsed fallback. For this dependency, use only pre-tested DNS, origin or bypass procedures and avoid broad security-rule changes made under pressure. Do not invent a new failover path during the outage.
5. Verify recovery end to end. A green DNSimple status is the start of validation: verify cache, DNS and certificate propagation before reversing incident changes.

What breaks when DNSimple has issues

DNSimple sits in the waf / cdn / dns layer. An incident can affect DNS resolution, TLS, caching, request filtering, routing and origin reachability; the exact blast radius depends on the components, regions and features your production path uses. Treat the official component timeline as evidence, compare it with your own independent probes, and communicate the user-visible effect rather than saying the whole vendor is simply “down.”