Reserved does not mean reliable.
RFC 2606 reserves example.com, example.net, and example.org for examples. It also reserves .test for testing DNS-related code, .invalid for names that should fail, and .localhost for loopback use.[2]
That reservation prevents naming conflicts. It does not promise an HTTP response. IANA says the web service on the example hosts is best effort and should not support production applications.[1]
A safe name in a README is not a service-level agreement.
The redesign exposed the hidden dependency.
DebugBear traced the recent example.com change. IANA split the page into basic HTML and a separate JavaScript file because automated traffic often skips the script. That cuts bandwidth on a heavily requested courtesy endpoint. The new page also says not to rely on it for testing or monitoring.[3]
The Hacker News thread quickly filled with guesses about broken tests and connectivity checks. The thread is useful as a warning, not proof that a specific test failed. It shows how easily a familiar public page becomes an unstated fixture.[4]
Split the network question into layers.
"Is the internet up?" is too broad for one green light. A DNS lookup can work while TLS fails. A TCP connection can work while the application returns the wrong body. A content assertion can fail after a harmless redesign while the service remains healthy.
Write the exact question first. Use an endpoint your team owns for service checks. Force the failure you expect the check to catch. Keep documentation examples on reserved names, but do not confuse the example with the fixture.
A test needs a failure you can schedule.
The breaker below drafts a test contract. It does not send traffic. The selected layer changes the target requirement and the observable. Four interlocks cover ownership, a controlled failure, an exact assertion, and cleanup.
A complete control bank means the template has all four sections. It does not mean the endpoint exists or the test passed.