# example.com Never Agreed to Be Your Health Check **Summary:** example.com now splits a small initial page from a fuller multilingual explanation. I would keep its best-effort HTTP service out of application health decisions and give each probe a destination suited to its purpose. - Canonical: https://markhuang.ai/news/example-com-never-agreed-health-check - Language: en - Author: [Mark Huang](https://markhuang.ai/about) - Published: 2026-10-06 - Section: News - Tags: example.com, IANA, Health Checks, Web Performance, Software Reliability - Source: [DebugBear](https://www.debugbear.com/blog/example-dot-com-redesign-history) - License: https://creativecommons.org/licenses/by-nc/4.0/ --- ![An open reference book with blank pages connected to a dense tangle of network cables](https://cdn.markhuang.ai/news/example-com-never-agreed-health-check/hero.webp) *A documentation example can become an operational dependency one convenient connection at a time. Conceptual illustration.* example.com has a new look, but the part I would pay attention to is the warning. [DebugBear's redesign history](https://www.debugbear.com/blog/example-dot-com-redesign-history) dates its move beyond a static English page to September 28, 2026, with explanations in six languages. The message remains blunt: use the domain in documentation, and avoid relying on its website for testing or monitoring. The redesign would send me back to my health checks. I would keep example.com in sample URLs and remove its HTTP availability from decisions about whether my application is healthy. A domain reserved for examples does not come with a promise to keep answering requests. The traffic explains why the operators care. In ["Being Exemplary,"](https://kimdavies.com/being-exemplary) Kim Davies says the example-domain service received roughly 50 billion requests in one week in September 2026. He reports that figure for the service, which covers multiple example domains. A courtesy website has acquired a workload that its documentation purpose never required. ## The animation has already changed DebugBear describes a version that cycled through languages every five seconds, with characters fading in separately. That is useful history, but it is not the implementation served when I inspected the source on October 6. The [live HTML](https://example.com) contains a short English explanation and loads a separate [JavaScript file](https://example.com/s.js). That script adds the other five translations, uses the browser's language preferences to put a supported language first, and leaves the translations on the page. It does not contain the rotation described in the article. I prefer that quieter arrangement. Someone looking for an explanation should be able to read it at their own pace. It also shows how quickly a test tied to a courtesy page's exact content can become stale. The maintainers can revise the explanation whenever they need to. ## Why the explanation lives in a separate file IANA's statement in DebugBear explains the split: most traffic is automated and tends not to fetch the JavaScript file, so a smaller initial page reduces the data those requests require. Human visitors can still get the fuller explanation through their browsers. Davies describes this as an experiment and says the operators will monitor it. He also cautions that the relevant cost is transferred data after compression, not simply the number of characters in a source file. Neither explanation provides a measured before-and-after bandwidth saving. I would treat the design rationale as credible and leave the size of the benefit open. I like spending more of the explanatory content on readers who can use it. The design accommodates the different behavior of people and automated callers. Whether those callers belong there is a separate problem. ## A familiar endpoint is a persuasive shortcut I can see why someone would choose example.com as a quick external destination. It is easy to remember. In the [Hacker News discussion](https://news.ycombinator.com/item?id=49971921), commenters describe using it to trigger captive Wi-Fi portals. Another argues that the domains have organically become a service regardless of the operators' intentions. I understand that expectation. Repeated availability makes a shortcut feel dependable. But I would want to know what behavior the operator promises to preserve before making a product depend on it. [IANA's guidance](https://www.iana.org/help/example-domains) makes the boundary explicit: the web service is best effort, is not designed to support production applications, and should not be a required operating HTTP dependency. The reservation protects the name's use in examples. It does not turn the response body into an API contract. This concern predates the redesign. [RFC 2606, published in June 1999,](https://www.rfc-editor.org/rfc/rfc2606) warned that test software can escape its testbed and documentation examples can end up running on the operational Internet. Reserving example names addresses confusion over names. It does not make every use of their servers appropriate. ## I would change what the check is allowed to conclude If a check requests example.com and receives a response, the narrow conclusion is that it got an answer to that request. That alone cannot establish whether my application's own backend is available. If the request fails, the result also cannot isolate the fault to my application. I would start with the conclusion each probe is supposed to support. For an application health decision, I want a documented endpoint that I control, with a response that represents the dependency I am checking. For an external connectivity probe, I would deliberately choose a destination intended for that purpose and decide how its failure should affect the product. I would still need to be careful about what an endpoint I own can prove. A check confined to my own infrastructure cannot answer every question about access to the wider Internet. The improvement is to separate those questions so an unrelated external failure does not automatically become an application outage. That is what I would take from the redesign. The translations help explain what example.com is for, and the smaller base page addresses the traffic already arriving. The change I would make in my own software is simpler: keep the example in the documentation, and give the health check an endpoint whose job includes being checked.