What this page is, and what it is not
I sell systems that run unattended. The question a buyer should ask before trusting one is how anyone would know if it stopped working correctly. Rather than answer that in the abstract, I apply the standard to the systems that run my own business, and I publish the result.
This page covers my infrastructure only. There is no client system in it, because no client engagement has been signed yet, and nothing here is presented as one. It is also separate from the fleet console at the top of the reliability page, which is a labeled simulation with sample data for a fictional company. The section below that console, and this page, describe real jobs read from the real database.
The jobs that run without me
Six jobs run on schedules. Two of them have an independent check behind them and appear on the public card. The other four are recorded and watched but not published, because their descriptions would invite a reader to guess at business volume, which is not a question this page should raise.
| Job | Schedule | What it does | Independent check |
|---|---|---|---|
| Retention purge | Daily | Deletes records past the retention windows published on the data-handling page | Counts rows before and after, and re-reads the same query to confirm they are gone |
| Deploy drift check | Hourly | Compares the commit this site is running against the head of the repository on GitHub | The two numbers come from different systems, and neither comes from the thing being checked |
| Watchdog | Hourly | Holds every other scheduled job to a time window and emails me when one goes quiet | None by design. It reports absence and never certifies presence. Its own freshness is checked once a day by the local chief-of-staff job |
| Morning digest | Daily | Emails me the day's operational summary | The email provider's delivery event, received by a signed webhook |
| Close-out watcher | Daily | Marks stale outreach dormant after its window, with no model call | Reads the rows back after writing them |
| Local chief-of-staff | Daily | Writes a facts-only status block into my planning file, reports in, and checks that the cloud jobs, the watchdog included, have run on time | None. Its heartbeat is watched by the watchdog |
Two more jobs were added on September 7, 2026: bounded research workers that wake only when a task is queued for them, with a spending cap per start and per day. They have a day of history and no place on this page until they have a record.
What verified means here
Every run records two things separately. The first is the job's own report that it finished. The second is whether the state the job was supposed to produce was then checked against the source of truth, by a read that could have contradicted the report. Only the second is called verified.
For the purge, the state is the absence of the rows it deleted, and the source of truth is the database, read after the deletion; if the rows were still there, that read would say so. For the deploy check, the state is the commit this site is running, and the source of truth is GitHub, which holds the head of the repository independently of the deployment that is asking. A run where the state matches is verified. A run where it does not is recorded as a failure, not hidden. A run where the check could not complete, or a build was still in flight, is left unverified, because nothing was confirmed either way.
The watchdog is excluded because it produces no state to check. It searches the ledger for jobs that have gone quiet and reports what it finds; running that search a second time is the same search, not a source of truth. So the watchdog never sets the verified flag. Its own freshness is checked by a different process, the local chief-of-staff job, which reads the same ledger once a day and raises the alarm if the watchdog has not run in two and a half hours; the watchdog checks that job's daily heartbeat in turn. Neither certifies itself.
Failed runs are recorded in full, including what they cost. A job that times out after several retries is the most expensive run there is, and recording spend only on success would hide exactly those.
The record so far
These figures come from a query run on September 7, 2026. The live cards on the reliability page update every hour and will drift from this table; when they do, the cards are right.
| Job | Runs since start | Verified | Not verified, and why | Last 30 days |
|---|---|---|---|---|
| Deploy drift check, since August 4 | 834 | 807 in sync | 23 drift checks, 2 failed checks, 2 unconfirmed (build in flight) | 720 runs, 707 verified, 9 drift checks, 2 failed checks, 2 unconfirmed |
| Retention purge, since July 28 | 42 | 42 | 0 | 30 runs, 30 verified |
| Morning digest, since July 28 | 42 | 29 delivery-confirmed | 13 unconfirmed (no delivery report, see below) | 30 runs, 18 confirmed, 12 unconfirmed |
| Watchdog, since August 9 | 692 | Never, by design | 692, not independently verified, by design | 692 runs, none verified |
Corrections, September 7, 2026, the day of publication. The deploy check's 30-day cell first read "9 drift hours" alone; the two failed checks from August 17 also sit inside that window, so the live card counts 11 failures, and the cell now says so. The lifetime row first counted the two failed checks twice, once on their own and once inside "4 unconfirmed", so its categories summed to 836 against 834 runs; the row now lists each run once. And the table counted "drift hours" while the episodes below describe 13 and 9 hours, which is 22; the unit is hourly checks, and the August episode was reported by 14 consecutive checks across 13 hours, which is where the 23 comes from. The table now counts checks. Later the same day the digest and watchdog rows still read "0" under the renamed "Not verified" column; the digest has 13 unconfirmed runs and the watchdog is never verified by design, and both cells now say so.
The digest's confirmation count is lower than its run count because the delivery webhook was added after the first runs and a confirmation only arrives when the provider reports delivery. An unconfirmed digest was probably delivered. It is recorded as unconfirmed anyway.
The bad days
Three episodes sit in that record, and each one is the reason the record is worth publishing.
August 5, 2026: 13 hours of drift reported by 14 consecutive hourly checks, cause never determined. Two commits were pushed a minute apart late on August 4. The second changed only the list of folders excluded from deployment. Production kept serving the first commit for 13 hours, and every hourly check in that span reported the gap. The drift check reported it on the first hour and emailed me once, then again at the 12-hour mark, as it is built to. The next push resolved it. I never established why the deployment did not happen, and the check cannot say why; that log lives with the hosting provider. What I know is that the site was fine, the repository was ahead of it by one harmless commit, and nothing detected the gap except the job built to detect it.
August 17, 2026: two hours of a failed check. GitHub answered two consecutive requests with a permission error. The check recorded itself as failed rather than guessing, and the third hour was normal. Those two runs count as errors in the table above, not as drift, because nothing was known about the deployment during them.
September 6 and 7, 2026: nine hours of drift from a branch deployed straight to production. One of the agents I work with deployed a development branch to production directly, minutes after a normal push from the main branch had gone live. From 10:20 that evening to 6:20 the next morning, nine hourly runs reported that production was not running the head of the repository. The branch was a superset of the main branch, so nothing a visitor saw regressed. The check emailed me once, held per the one-alert-per-episode rule, and resynced when the branch was merged and pushed properly. The rule that came out of it is now written down. Production deploys from a push to the main branch, and from nothing else.
Nothing in this section was edited after the fact to look better. The query that produced the numbers is the same one the reliability card runs.
What this record does not prove
It does not prove the website works. Matching commits and a broken page are perfectly compatible. Whether a page works is tested by eight build gates that fail the deploy if authored copy and built output disagree, and by a person opening the page afterward.
It does not measure uptime. There is no probe hitting the fifteen API endpoints on a schedule yet, so a route that quietly disappeared in a deploy would not show here until something else depended on it. Two routes that matter most, the voicemail handler and the call notifier, are probed by the watchdog; the rest are not.
It says nothing about any client system. When one is reported this way, the monthly accuracy report will be built on the same method, and this page will say so.
And a verified flag is only as good as the independence of the second source. If I ever route the deploy check through the deployment it is checking, the flag becomes a self-report with a green color, and this page would have to say that too.
The rules I hold myself to
These govern what appears on the public card and on this page. They are written down so that a bad month cannot quietly change them.
- A job appears on the public card only after seven runs in thirty days. Below that, it does not appear at all. No empty state, no placeholder.
- A job appears only if its description discloses nothing about how many clients exist or how much work is flowing.
- Verified means the state a job was supposed to produce was checked against the source of truth by a read that could have contradicted it. A job re-running its own search does not count. The watchdog never sets it.
- Every drift hour and every failed check counts against the job on the public card. Nothing is filtered out as a special case.
- One alert per episode, then one every twelve hours. Eight identical emails overnight is how alerts get muted, and a muted alert is a silent failure with extra steps.
- A correction to this page is dated and visible. A number is never rewritten in place.
- When a client's system is reported this way, the client may ask for a publication delay. The client may not remove an incident from the count. Any funding behind a published analysis is disclosed on it.
The last rule is borrowed, with credit, from the ethics page that Kyle Kingsbury publishes for Jepsen's database testing reports. It is the clearest statement I have found of what independent evidence requires from the person publishing it.
Questions people ask
Is this the same data as the reliability page?
Partly. The reliability page has two parts. The fleet console at the top is a labeled simulation with sample data for a fictional company, and it will stay labeled. The section below it, headed as my own infrastructure, reads the same database this page describes and updates every hour. This page is the written account of that record, with the dates and the causes that a live card cannot carry.
Why would a consultant publish his own failures?
Because a record with no bad days reads as a brochure. The two drift episodes are the evidence that the check works, and the point of the check is to catch the thing nobody would otherwise notice. A client's monthly accuracy report will carry its bad days the same way, and I would rather show that habit here first.
Does a verified deploy check mean the website works?
No. It means the code running in production is the code at the head of the repository. Matching commits and a broken page are perfectly compatible. Whether a page works is tested by eight build gates before a deploy is allowed, and by a person looking at it after.
What happens when a job goes quiet?
A separate hourly watchdog holds every scheduled job to a time window and emails me when one has not reported inside it. It never marks anything verified itself, because it produces no state that a source of truth could confirm. Its own freshness is checked once a day by the local chief-of-staff job, and the watchdog checks that job's heartbeat in turn, so neither one certifies itself.
Will the numbers on this page go stale?
Yes. Every figure here is dated September 7, 2026 and comes from a query I ran that day. The live card on the reliability page is the current number. When I update this page, the date at the top moves and the change is noted in the record section rather than silently rewritten.