Every delivery estate has a person who knows where everything is — which hostname fronts which origin, which dashboard holds the purge button, when the contract renews. That person is a single point of failure with a calendar and a notice period. The fix costs an afternoon: one page, in version control, that lets a competent engineer who has never touched your estate act correctly at 3 a.m. Here is what goes on it, and — harder — how it stays true.
Why one page, and what it is for
One page is a discipline, not a limit on truth: the estate document is a map, linking outward to configs, runbooks and contracts — never a copy of them, because copies rot and maps age gracefully. Its audiences define its content: the on-call engineer mid-incident (what fronts what, where the switches are, who to call), the new team member in week one (the tour in the training plan literally walks this page), the auditor or reviewer (the quarterly audit and annual review both open it first), and finance (the hostname-to-product map from spend allocation is this page’s map wearing its other hat). It lives in the repo beside the delivery config, and its link is pinned in the incident channel — findability is half its value.
The map section: names, paths, providers
The core is one table, one row per user-facing hostname: hostname → CDN provider(s) and the config/distribution identifier → origin (what actually serves misses, and where it runs) → DNS arrangement (which zone, steered or plain, per the DNS setup) → certificate arrangement (managed by whom, validated how) → owning team. Add the estate-level facts a newcomer cannot infer: the multi-CDN pattern if you run one (which architecture, what steers it), the origin-protection posture (allowlists? mTLS? private connectivity — the rung from the ladder), and the two or three deliberate oddities every estate has — the legacy hostname that bypasses the CDN, the partner path with the special rules — because undocumented oddities are what turn incidents into archaeology.
The operational section: access, contacts, runbooks
The section the 3 a.m. reader actually came for. Access: where each provider’s console lives and how access is granted (the group, not the person — and never credentials themselves; those live in the secrets manager this section points to). Contacts: per provider — support portal, severity-1 phone path, account team names, and your customer/contract ID printed right there, because hunting for a contract number during an outage is a rite of passage nobody needs. Runbook links: the CDN-outage playbook, the DDoS runbook, the failover drill notes, the purge procedure — each one line, each a link. Monitoring: where the delivery dashboards live, which alerts page whom. The test for this section is brutal and worth actually running once: hand the page to an engineer from another team and time how long until they can say who they’d call and which switch they’d consider.
The commercial section: contracts and dates
Five lines per provider keep the money side ambush-free: contract term and renewal date with the notice deadline (the date that, missed, auto-renews you — deserves bold and a calendar entry), commit size and overage structure in one sentence (the detail lives in the commit file this line links to), support tier, the SLA one-pager link from the credits guide, and where the invoices and monthly review notes live. This section exists because commercial memory is the first casualty of team change: renewal dates surprise precisely those estates where the person who signed has moved on — and a renewal that arrives as a surprise is a negotiation already half-lost, as the renewal guide opens by observing.
Keeping it true: ownership and triggers
Documents do not rot from laziness; they rot from having no update mechanism, so install three. An owner: one name accountable not for writing every update but for the page being current — rotating annually is fine; “the team” is not an owner. Change triggers: the definition-of-done for estate-touching changes includes the page — new hostname, provider change, contract renewal, contact change each carry a one-line edit, enforced the cheap way by putting the page in the same repo so config PRs can touch it in the same commit. A staleness backstop: the quarterly audit’s first item is “read the page, fix what’s wrong” — ten minutes that catches whatever the triggers missed. Version control gives the rest for free: history of what changed when, blame for questions, and diffs that make the annual review’s “what changed this year” section write itself. An afternoon to create, minutes a month to maintain, and one incident’s confusion repaid — the best-yielding page in the estate.