La Bouchée's website is kept running by scheduled jobs on a Raspberry Pi. Some of them use an LLM to draft things, such as a reply to a new Google review or a proposed change to a page, and a person approves each draft before it goes anywhere. The job that checks whether all of this is working uses no model at all. It is a few hundred lines of Python with nothing outside the standard library.
What it checks
Every 30 minutes it looks at:
- the four pages customers order from, each of which has to load where it was asked for, return a success status and carry its own canonical address;
- the contact page's quote form, which has to carry the form key that has been proven to deliver a request;
- the form service the quote form posts to, which has to answer;
- the site's certificate, which has to have more than three weeks left;
- the sitemap, which has to parse and list the site's pages;
- every other job in the system, each of which has to be enabled, recent and free of errors. A job that no rule covers counts as a problem too, because nothing would notice if it stopped.
When something fails, it prints one line, and that line becomes a message on a phone. The same problem is not repeated for six hours. A second plain script turns each problem into a ticket and closes the ticket when the watchdog stops reporting it. When everything is healthy the watchdog prints nothing, and when a problem clears it prints one line saying so.
Why no model
The status an agent job leaves behind is the agent's account of its own run, and I have watched that account go wrong in both directions.
In early August a nightly LLM job stopped running after a configuration change. The scheduler skipped it to avoid unplanned spending, and nothing reported it for days. A plain-code check found it on its first run.
In September an LLM job that prepares site changes as a pull request hit a git error when it tried to commit. The agent repaired the problem itself, carried on, and the pull request arrived. The run was recorded as a success. Only a separate check that reads the exit code of every command an agent runs saw the failure. The repair was the real problem. It lived in a working copy that a fresh clone would lose, and every later run depended on the model improvising the same fix. The fix now sits in the command itself, and a test fails if a job definition leaves it out.
It also happens the other way round. A drafting job did all its work and was still recorded as failed, because the model's final reply came back empty.
A watchdog exists to be believed. If it were an agent, its report would be one more statement by an agent, and something else would have to check it.
Plain code gets it wrong too
For more than two weeks in August the site sat behind its maintenance page, and every page check stayed green. The checker followed the redirect without noticing, and the words it looked for (the bakery's name and the form service's name) also appeared on the maintenance page.
The fix was to check each page where it actually landed and to require each page's own canonical address, which the maintenance page cannot carry. A test now feeds the maintenance page through the page checks and expects every one of them to fail.
That is the difference I care about. A wrong rule in code fails the same way every time, anyone can find it by reading the code, and once a test pins the fix it stays fixed.
What it has caught
Two pages that timed out and recovered within half an hour. A ticket script that crashed, several times. A weekly report that broke on a type error. A drafting job that failed. One day in September the Pi's own DNS failed, every check failed at once, and eight tickets opened and closed together two hours later. That was the server's problem rather than the site's, and the record shows it plainly.
It has not yet caught an expiring certificate or a broken form. The certificate, sitemap and form-service checks are also its least tested parts, because the test suite stubs them. The 38 tests that exist cover the page checks and the alerting end to end, through real state files.
Where the models do sit
Wherever a model writes something a customer will see, it only drafts, and a person approves it first. The case study shows each of those jobs. The job that tells me whether any of it is working stays as plain as I can make it.