Ingestion status.

The ledger reconciles

The check that decides whether any of this is worth reading. If the gap ledger were decorative, the cycles it claims were missed would not add up to the cycles that are absent.

Those two totals land on each other inside the tolerance, so the missing time is accounted for rather than quietly dropped. The tolerance is 2 percent of the expected count or 5 cycles, whichever is larger, because the cadence is a mean and not a fixed tick. That slack is also the limit of this check, and it is worth naming: at the current tolerance of 250 cycles, an outage the ledger never recorded would pass unnoticed here if it were shorter than about 4h 36m. Because the tolerance is a percentage of the expected count rather than a fixed number, that blind spot widens the longer this service runs. The check catches a ledger that dropped a long outage, and it gets steadily weaker against one that dropped a short one.

The publisher's own days_running figure differs from the interval between its two timestamps by 22 seconds, which is the lag between measuring and writing. The elapsed figure above is the interval, so it sits on the same clock as the gap rows.

elapsed = published_at minus first_cycle_at, falling back to days_running x 86400 if either timestamp is unreadable. ingesting = elapsed minus the recorded gaps, with overlapping intervals merged before they are added up. expected cycles = elapsed / cadence_seconds, and cadence_seconds is a mean, so that count is good to a few cycles and not to one. every input is a column the publisher wrote.

Quality gates 4 of 4 passing

The ingestion checks the poller runs against itself: disk headroom, freshness, volume and null rates. The detail below is copied from the snapshot exactly as the machine wrote it.

• ✓ disk 34.4 GiB free on /System/Volumes/Data
• ✓ freshness last poll_runs row -1.2 min ago
• ✓ volume 234829 rows inserted (poll_runs) in the last hour
• ✓ null_rate scheduled_arrival null-rate 2.73% over last hour (6556/239875)

One of those strings reports a negative age. An age is the reading clock minus the row's timestamp, so a negative one means the row is stamped slightly ahead of the clock that read it. It is left as the machine wrote it rather than rounded up to zero, because rounding it would hide the only evidence that the two clocks disagree.

Where this runs

The warehouse is Postgres on a Mac in my apartment. It is not a managed cloud service and this page does not pretend it is. The Mac publishes a snapshot of its own counters to a Cloudflare D1 database on a 5 minute interval. This page reads the newest snapshot and shows how old it is, every time.

That is the whole trick. If the Mac sleeps, loses power or loses network, the snapshot stops moving, the age climbs, and this page says so in plain words instead of showing an old number as if it were current. The threshold for saying so is 15 minutes.

What these numbers are not

• Uptime here counts from the first poll cycle, not from an install date. Today it is a small number, and I print it to two decimals rather than rounding it into something rounder.
• The cadence is measured, not configured. The interval is set at 60 seconds, and the work inside each cycle pushes the real spacing above that. The measured figure is the one shown.
• This is a single machine with a single power supply. There is no failover. I wrote the gap ledger because of that, not in spite of it.