The website was working. The analytics were dead.
A rendered page can conceal a failed business dependency.
Wolfe Services · · 4 min read
The homepage loaded. The contact form still worked. The site looked healthy enough to pass the kind of inspection a busy firm owner can reasonably give it between meetings.
In April 2026, the analytics delivery path on the JTNY site was broken. Our operating records trace the incident to deployments that ran the framework build but skipped the rest of the production pipeline. A piece of code responsible for forwarding measurement requests was missing from the deployed output.
We are including the failure here because a firm should know what its website operator is responsible for. The visible page is only one part of the product. What happens after a visitor submits a form depends on several other parts doing their jobs.
The failure was behind the page
The site sends analytics through a first-party route. A build step installs the handler for that route into the production worker. If someone runs only the framework compiler, it can produce a perfectly serviceable set of pages without that handler.
During the incident, measurement requests reached the wrong routing behavior instead of the intended forwarding path. The page could render while delivery to analytics failed. Looking at the homepage, or even successfully submitting a form, did not test the missing dependency.
This distinction matters when a firm reads its next report. A drop in recorded leads might reflect a problem with demand, a form, or the measurement path. Those are different problems with different remedies. Changing an advertising budget before establishing which one occurred can make the original failure more expensive.
Our records agree on the deployment mechanism but use different boundaries for the affected period. We are therefore describing an April incident rather than claiming a precise outage duration or a recovered lead total. The engineering lesson does not require either number.
The build command became an operating contract
We corrected the release process to use the complete build pipeline and documented it as part of the application.
That includes the steps after the framework finishes: installing production routing behavior, preparing assets and metadata, and verifying that required output exists. A developer taking over the repository needs to know which command creates a deployable artifact. An instruction buried in a chat cannot carry that responsibility.
This is one reason we are building AstroPress around explicit publishing and deployment rules. Astro gives us a useful foundation, but choosing Astro does not by itself prevent a broken measurement route. The surrounding checks have to encode what the business depends on.
The same principle applies to a WordPress installation, a custom application, or a hosted builder. The important question is whether the release process can distinguish a successful page build from a complete working system.
Four checks answer different questions
We now document several checks around this measurement path. They are deliberately separate because each can pass while another fails.
| Check | What it establishes | What it does not establish |
|---|---|---|
| Inspect the built artifact | The required handler is present | It works on the production domain |
| Send a production request | The expected route answers | The analytics provider accepted the event |
| Exercise the bot rule | A known automated client is handled as intended | All automation is filtered |
| Look for the event downstream | A test event reached the reporting system | Every real inquiry is measured correctly |
A successful HTTP response is useful evidence at one boundary. It is not a substitute for following the event through to its destination. Equally, a downstream test event cannot prove that the numbers in a monthly growth report are clean. We encountered that separate problem in the traffic increase we stopped celebrating.
For a firm, these checks should produce a short release record. What changed? Which production path was exercised? Did the expected event appear? Who owns the investigation if it did not? You should not need to interpret a terminal log to learn whether the person shipping a change checked the business dependency.
The diagnostic to take to your team
Ask whoever operates your site to demonstrate one inquiry through the system using an approved test record. Start with the public page and follow the record into the place your staff actually works. Then ask where the associated measurement appears.
Have them explain what would happen if the measurement endpoint returned a redirect, if the inbox integration were unavailable, or if a deploy omitted a required post-build step. The answer should identify a check or a recovery path. “We would notice the numbers were down” leaves the detection period open-ended.
Finally, ask whether another engineer could perform that demonstration from the written runbook. This is a practical ownership test: access to a repository is more useful when it comes with the knowledge needed to operate it.
The evidence here supports a specific conclusion. Our release process had a failure mode that left the website visible while analytics delivery failed, and the operating contract now checks that dependency. It does not establish an increase in rankings or revenue. Before asking a dashboard to explain growth, we need to know that the events it depends on can arrive.