CONCEPT Cited by 1 source
Dependency on self¶
A circular-dependency failure mode where an organisation operates the product it itself depends on — "X runs on X" — so that an outage of the product takes out the very tools the operators need to fix the outage.
The concept is canonicalised in Cloudflare's 2026-05-01 Code Orange: Fail Small is complete post:
Cloudflare runs on Cloudflare. We use our own Zero Trust products to secure our infrastructure, but this creates a dependency: if a network-wide outage impacts these tools, we lose the very pathways we need to fix them.
The failure shape¶
During a normal incident, operators access the production environment via the normal pathways — VPN / Zero Trust identity proxy / SSO / CI-CD pipeline / dashboard. Dependency on self means those pathways themselves depend on the thing that is currently broken. Concrete manifestations:
- Zero Trust proxy (the example Cloudflare names) — if the proxy is broken, operators can't log in to the boxes that run the proxy.
- SSO/IdP — if the identity provider is the broken system, nobody can authenticate to any tool.
- DNS / resolver — if the DNS service is broken, even the internal tooling URLs don't resolve.
- CI/CD pipeline — if the pipeline depends on the broken product (e.g., runs jobs on Lambda while Lambda is down), operators can't ship a fix through the normal path.
- Dashboard / status page / incident-management tool — if these are hosted on the broken product, operators and customers have no visibility.
Why it's structural¶
Dogfooding is Cloudflare's explicit strategic posture (canon- icalised in companies/cloudflare's "dogfood the platform as internal infra" recurring shape). The circular dependency is the price; the benefits (discovering customer-visible failure modes before customers, forcing internal teams onto the public platform) outweigh the cost under normal operation. Under outage, the cost is exposed.
The concept is not an argument against dogfooding. It is the structural hazard dogfooding creates, which requires explicit engineering — backup authorisation pathways — to compensate for.
Cloudflare's named remediation¶
From the 2026-05-01 post:
To solve this, we conducted a comprehensive audit of the tools essential for system visibility, debugging, and production changes. We ultimately developed backup authorization pathways for 18 key services, supported by new emergency scripts and proxies.
And critically, the remediation is drilled, not just built:
After small-team exercises, we conducted an engineering- wide drill on April 7, 2026, involving more than 200 team members. While automation keeps these pathways functional, drills like these ensure our engineers have the muscle memory to use them under pressure.
See concepts/break-glass-escape-hatch for the escape-hatch pattern and concepts/drill-muscle-memory for the exercise discipline.
Sibling concept¶
concepts/runtime-dependency-on-saas-provider is the externally-facing sibling: the concern is that we run on their SaaS (and its dependency chain). Dependency on self is the internally-facing sibling: the concern is that we run on ourselves. Both produce the same structural shape — a hazard that eats the recovery pathway — but the remediations differ:
- External SaaS dependency → diversify providers, cache state, remove from hot path.
- Self dependency → backup authorisation, emergency scripts, drill regularly.
Sibling tier¶
concepts/cdn-as-critical-internet-infrastructure is the customer-facing sibling: Cloudflare's self-dependency matters because a broken Cloudflare takes down a measurable fraction of the visible web. The urgency of Code Orange — why the backup- authorisation audit covered 18 services and why the drill ran at engineering-org scale — sits on the same axis.
Canonical wiki instance¶
sources/2026-05-01-cloudflare-code-orange-fail-small-complete — Cloudflare explicitly names "Cloudflare runs on Cloudflare" as a structural hazard and describes the remediation (backup-authorisation pathways for 18 services + 2026-04-07 engineering-wide drill with 200+ participants). The sibling Cloudflare posts sources/2025-11-18-cloudflare-outage-on-november-18-2025 and sources/2025-12-05-cloudflare-outage-on-december-5-2025 each surfaced the specific manifestations (dashboard login via Turnstile during the 11-18 incident; Zero Trust Access cascading through Workers KV).
Seen in¶
- sources/2026-05-01-cloudflare-code-orange-fail-small-complete — canonical wiki instance; "Cloudflare runs on Cloudflare" named; remediation shipped + drilled.
- sources/2025-11-18-cloudflare-outage-on-november-18-2025 — manifestation: dashboard login blocked because Turnstile couldn't load while the core proxy returned 5xx.
- sources/2025-12-05-cloudflare-outage-on-december-5-2025 — manifestation: sibling surface failure affecting parts of the control plane via FL1 proxy.
Related¶
- concepts/break-glass-escape-hatch — the escape-hatch primitive the remediation builds on.
- concepts/runtime-dependency-on-saas-provider — the externally-facing sibling concept.
- concepts/drill-muscle-memory — the operational discipline that makes the backup pathways usable under pressure.
- concepts/cdn-as-critical-internet-infrastructure — the customer-facing urgency axis.
- systems/cloudflare-zero-trust-access — the dogfood-via-own-product instance Cloudflare names.