A manifest listing five hostnames beside a platform config that owns none of them means the honest answer for all five is “nowhere.”
A deploy manifest and a platform’s own routing config can both claim to describe the same decision — which hostnames a service answers on — and disagree with each other indefinitely, because nothing forces them to agree. One of them is the one the platform actually reads. The other is a document that looks equally authoritative and isn’t, and the failure mode isn’t that anyone notices the mismatch. It’s that nobody has a reason to check, because both files read as complete.
The concrete mechanism is almost always the same shape: a manifest field that was designed to be informational — printed for a human to eyeball, never parsed into an actual deploy step — sitting next to the platform’s real configuration, which is the only place routes actually get applied. List five hostnames in the informational field and none of them in the platform’s own route block, and the service comes up fine, passes its build, and answers on the platform’s default address instead of any of the five domains anyone actually expected.
What makes this worse than an obvious misconfiguration is that everything upstream of the mismatch looks healthy. The deploy succeeds. The build passes. Only a health check that specifically targets the real domain — not the platform default — catches that nothing is actually listening where it’s supposed to be, and if that health check doesn’t exist, or checks the default address instead, the gap can sit there for a long time, discovered only when a person tries to visit the domain and gets nothing. A build passing and a domain actually answering are two different claims, and treating the first as proof of the second is the same shape of mistake as trusting any other status that looks like evidence and isn’t.
The informational field wins someone’s trust eventually for a simple reason: it’s the one people actually read. It sits in the manifest, in plain language, next to the other settings a person configuring the service would naturally look at. The platform’s own config is often buried in a format the platform itself generated or expects in a specific dialect, less inviting to read casually — so the readable-but-wrong file becomes the mental model, and the correct-but-buried file stays correct and ignored until something breaks against it.
It also survives handoffs particularly badly. The person who set up the platform config knew, at the time, that the manifest field was decorative — that knowledge lived in their head, not in either file. The next person to touch the project inherits two files that look equally authoritative and no note explaining which one is real, and can pick the wrong one, because nothing in either document says “ignore me.” Every rotation repeats the same ambiguity — each new person inherits the same two files and the same missing note, and anyone who guessed wrong and got away with it for a while has no reason to ever go back and check which file was actually true.
The actual fix is to collapse it to one source of truth and make everything else either derive from it or not exist. If a manifest wants to describe routes for a human to review, fine — but it has to be generated from the platform’s real config, not maintained in parallel by hand, because two hand-maintained descriptions of the same fact will drift the first time someone updates one and forgets the other, and drift between two authoritative-looking documents is invisible until it isn’t.
This is a specific instance of a general outage class: two files, two systems, or two people each holding a partial, plausible-looking copy of a fact that only one of them actually enforces. The lesson isn’t specific to deploy manifests — it’s that any config surface allowed to look authoritative without actually being read by the thing it describes will eventually be trusted by someone who had no way of knowing it was decorative.