Atelier Multidécor builds custom kitchens and cabinetry in Saint-Siméon-de-Bonaventure, in Quebec’s Gaspésie region, and has since 1994. Telos Machina hosts and maintains the shop’s site on Cloudflare Workers. In the summer of 2026, the external uptime monitor started flagging an outage several times a day, while every manual check showed a fast, working site with no errors. This piece documents the diagnosis that followed, the fix, and the speed and structure work that came with it. It contains no traffic, ranking, or revenue numbers. That data is tracked elsewhere, outside this article.
The monitor that cried wolf
The uptime monitor has watched ateliermultidecor.com since July 13, 2026. From that date on, the alert kept coming back several times a day, always the same message: a 48-second timeout exceeded. Never a status code. Never a connection error.
Every time we checked the site by hand during an alert, it answered normally, in a fraction of a second. The simplest explanation, in this kind of situation, is that the monitor itself has a problem: network, name resolution, or a misconfigured tool. Three checks closed that line of inquiry.
Seven other sites watched by the same tool, from the same container, the same DNS resolution and the same Cloudflare address, stayed at 100% uptime through the entire window: telosmachina.ai, anniedallaire.ca, 21km.ca, gazonnet.ca, and two internal tools. DNS resolution for the Atelier Multidécor site was byte-for-byte identical to the healthy sites. All eight monitors shared the exact same check interval, timeout, and retry count. The monitor wasn’t the problem.
An outage real visitors never saw
The second theory was more worrying: that the site really was slowing down intermittently, and ordinary visitors were paying for it without complaining. Cloudflare’s own network logs settled the question the other way.
During the hours when every monitoring probe sat stuck, more than 800 real requests completed successfully in that same hour, with zero errors. The site was not down. It was down for exactly one kind of visitor: the monitoring probe itself.
The signal in the execution logs
The answer sat in the Worker’s own execution logs, the program that handles every request on Cloudflare’s network. Every stuck call showed the identical fingerprint: about 78 seconds of wait time, about 5 milliseconds of actual compute, and zero completed sub-requests. A visitor who closes the page mid-load leaves a completely different trace, around half a second on both numbers.
The hourly count of stuck calls matched the hourly count of monitor alerts exactly: three stuck calls at 2 PM against three alerts, nine against nine at 3 PM, ten against ten at 4 PM, zero against zero between 10 AM and 1 PM. A matching number in two unrelated systems stops being a coincidence.
The cause: a Worker waiting on itself
The cause turned out to be one sentence once found. Versions of the hosting adapter below 1.20.1 have the Worker call itself through an ordinary web request, to service its own page-refresh queue, the mechanism that keeps a page current without rebuilding the whole site on every visit.
Cloudflare does not allow that kind of call. A Worker cannot invoke itself through a plain web request on the same account. The request sat waiting forever, which is exactly the signature we saw: almost no compute, no completed sub-request, a timeout that finally expires on the visitor’s side instead of the server’s. Version 1.20.1 replaced that self-call with an internal mechanism built for this exact kind of communication.
Why this kind of diagnosis matters
A plumber who doesn’t know why a pipe is leaking patches the visible symptom and waits for the next leak. The same shortcut exists in web hosting. Without the Worker’s own execution logs, the easiest move would have been to blame the monitor, turn down the alert frequency, or write the failures off as noise.
None of those three moves would have fixed anything. The Worker would have kept hanging on the same requests. The diagnosis cost log-reading time instead of a quick patch. That’s the trade we make every time a signal doesn’t mean what it looks like it means.
The trap in a clean run
The fix itself moved fast once the cause was known: update the hosting adapter and Next.js, the site’s underlying engine. Confirming it took longer, and nearly fooled the team three separate times.
Every new deploy resets every running copy of the site worldwide. A clean stretch right after a deploy proves nothing: it would look the same whether the fix worked or not. The discipline we settled on was to first measure the best clean stretch the old, unfixed code had itself managed between two incidents: 30 hours and 23 minutes. The fix only counted as confirmed the day it beat that number, on July 30, at 46 hours and 44 minutes without an incident.
A stricter bar, seven straight days with no deploy at all in between, has still never been met: the site keeps changing, and every new deploy resets the clock. A site under active, ongoing work may never clear that kind of bar.
A security gap closed along the way
The update fixed something else on its way through. The site was running Next.js 16.1.6, a version below the floor Telos Machina requires on its own sites (16.2.6 or newer) because of a known flaw in language handling (CVE-2026-44573) that lets an attacker bypass certain bilingual routing rules. The new hosting adapter requires Next.js 16.2.6 or newer to run at all.
The phantom outage and the security flaw got closed in the same deploy, on July 27, 2026. Two unrelated problems, fixed by the same version bump. That doesn’t happen often, so it’s worth writing down.
The rest of the work: speed, images, and structure
Diagnosing the phantom outage was only part of the job. A series of speed and image fixes followed, each measured before and after. LCP, the time it takes the largest visible element on a page to render, is the metric Google uses to judge how fast a page feels.
| Metric | Before | After |
|---|---|---|
| Accessibility score (mobile Lighthouse) | 96 | 100 |
| Home page HTML weight | 333,283 bytes | 86,042 bytes |
| Header image (AVIF format) | 253 KB | 25 KB |
| Preloaded fonts | 10 | 4 |
| Home page LCP (logo fix) | 7.1s | 6.4s |
| Town-page LCP (main image loaded with priority) | 5.1s | 3.8s |
| Mobile Lighthouse score, town page | 79 | 88 |
Most of the HTML weight cut came from a translation file that was loading both of the site’s languages at once instead of only the one requested. The ten fonts preloaded at the start weighed 376 kilobytes together and were slowing down the largest visible element instead of speeding it up, the opposite of what preloading is supposed to do. Four fonts remain.
A separate bug caused a loop on unknown site addresses: every missing page replayed a redirect twenty times over before stopping, on every single load. Fixed September 2.
The sitemap, the file that lists every page for search engines, held 64 addresses on August 5. It holds 92 today, including twelve pages built for individual towns across Gaspésie and the Bas-Saint-Laurent, each written for its own location rather than copied from one town to the next. The site also picked up the technical structure Telos Machina runs on its own pages: structured data per page, French-English correspondence for search engines, automatic submission of new addresses, and open access for content-reading bots instead of the reflexive blocking many sites apply today. Eighteen real photographs of Félix Gagné’s work, the cabinet maker behind the shop, replaced generic or AI-generated images across the main pages in early September.
FAQ
Did the Atelier Multidécor site actually go down?
Not for its visitors. The uptime monitor reported an outage several times a day, but real visits in the same hour all completed successfully. The outage was real. It just wasn’t where it looked like it was.
What was causing the problem?
A bug in the program that hosts the site on Cloudflare’s network, present in every version below 1.20.1. That program was calling itself to service its own page-refresh queue, an operation Cloudflare does not allow between two copies of the same site. The request sat waiting for a reply that would never arrive.
Would a business owner ever notice a bug like this?
Rarely. It doesn’t crash the site for a customer browsing normally. It hides in hosting logs and in the behavior of an external monitoring tool, which is exactly why it can run for weeks unnoticed.
Where can I see the search results from this project?
Not here. This piece documents what was diagnosed and fixed on the site itself. Search-visibility numbers are tracked elsewhere and are not part of this article.
We fix this kind of outage with the same discipline documented here: establish what a system is actually doing before deciding how to fix it. Our websites page covers how we approach hosting and speed for a hands-on trade business.