Is Bunny.net down right now?

While you wait: the Bunny.net incident checklist

1. Name the dependency precisely. Bunny.net 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 Bunny.net'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 Bunny.net 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 Bunny.net status is the start of validation: verify cache, DNS and certificate propagation before reversing incident changes.

What breaks when Bunny.net has issues

Bunny.net 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.”