Notifications
Clear all
Topic starter
02/08/2026 12:05 pm
TL;DR: Nine partial downtime or slowness periods in one month were mostly resolved in under an hour, with existing data-plane connections continuing even when control-plane actions were blocked for affected users, according to Tailscale. The pattern shows why blast radius, not just uptime, is the critical reliability measure for identity-adjacent infrastructure.
NHIMG editorial — based on content published by Tailscale: Hypergrowth isn't always easy
By the numbers:
- One incident on Jan. 5 took 24 minutes and affected a small number of tailnets.
Questions worth separating out
Q: What breaks when a control plane is unavailable but data traffic still works?
A: The first failures are usually administrative, not data-path.
Q: Why do centralised coordination services create blast-radius risk?
A: They concentrate state and policy propagation into a path that many actions depend on.
Q: How do organisations know if control-plane resilience is actually working?
A: They should test whether critical actions still succeed under partition, shard loss, or client restart.
Practitioner guidance
- Map control-plane dependencies for access changes Identify which IAM, NHI, or network actions fail when the coordination layer is unavailable, including approvals, policy pushes, node onboarding, and emergency revocation.
- Test cached-state recovery paths Verify that clients, agents, or workloads can continue operating from cached state after a restart or temporary partition.
- Measure outage impact by affected actions Track whether incidents blocked administrative actions, not just whether traffic continued.
What's in the full article
Tailscale’s full post covers the operational detail this post intentionally leaves for the source:
- The incident-by-incident uptime history and the specific Jan. 5 outage details.
- The architectural explanation of coordination sharding, hot spares, and live migration.
- The client restart caching change that reduces dependence on live coordination state.
- The reliability roadmap items tied to multi-tailnet sharing and regional structure.
👉 Read Tailscale’s analysis of control-plane outages and architecture resilience →
Control-plane outages: what it means for IAM teams?
Explore further
02/08/2026 1:10 pm
Blast-radius control is the real reliability metric for identity-adjacent platforms. A control plane can be technically available in one part of the stack while still blocking the actions that matter most to administrators and security teams. That is why partial outages must be assessed by who can no longer make access changes, approve devices, or enforce policy, not just by whether existing sessions survive.
A question worth separating out:
Q: Who is accountable when access management depends on a fragile control plane?
A: Accountability sits with the platform and the security owners who chose the architecture, because control-plane failure is a governance issue as well as an uptime issue. Frameworks such as NIST SP 800-53 and NIST CSF both expect access control, change control, and system resilience to be managed deliberately.
👉 Read our full editorial: Tailscale’s control-plane outages show why blast radius matters
