Mindbridge ยท track status

MEASUREMENT

This track asks whether anything tells us when a customer's ingestion has stopped โ€” and the answer today is no: the tenant-health score was deferred, and the one open item is a connector dying silently.

Re-measured 2026-08-16. This page has never been published โ€” publish fresh per docs/status/artifacts.json. Verify before starting: the production counts below (dead Gmail grants, logged-out WhatsApp sessions) are a point-in-time snapshot from the issue and decay.

Next โ†’ #3060 connector-liveness โ€” the only open item, and it survives the score's deferral because it is not a measurement problem.
The tenant-health score is deferred โ€” the 1 open issue on the label is the survivor: connector-liveness, which outlived the deferral because it is not a measurement problem.
Open workWhy this orderStanding rulingsHistory

Open work

Connector-liveness โ€” the only open work
p1 #3060 Nothing tells us when a customer's connector dies โ€” the health score can't, and shouldn't dead connector raises no alarm Mizo

A dead OAuth grant leaves the connector row in place with status="error" โ€” the connector stops delivering and nothing anywhere raises its hand. Five Gmail grants are in that state on production right now, and two WhatsApp sessions are logged out; nobody is told.

ADR-135 defect #9 marks this fixed (PR #2816) โ€” accurate about stopping get_status from returning connected: true for a dead grant, and it added no monitoring; the state has been correct and unobserved since.

Not the health score's job. A score is something you look at; a dying connector is an event that has to find you. Encoding it as a number on a platform panel nobody opens daily is strictly worse than an alert, and it drags an ingestion concern into a per-tenant graph-quality metric.

What already exists: branch feat/connector-health-kpi โ€” three commits, 24 tests, mypy clean, 4-lens reviewed, unmerged. It adds a connectors_errored count covering both connector state machines, measured 7 of 21 on production. It is deliberately not the alarm: it does not page (dead grants are the designed behaviour under the Testing OAuth app โ€” Google expires every token 7 days after consent โ€” and re-firing every ten minutes would reproduce the known Bugsink flood), and it is fleet-wide, so it cannot name a tenant.

Done is someone being told, promptly, which account's connector died โ€” without being told again every ten minutes about the ones they already know. Open design questions: alert on the transition into error rather than the standing state; whether the alert is fleet-wide with tenant detail attached, or per-tenant; breach_at becomes meaningful once the OAuth app leaves Testing.

The 7-day expiry is an asset: Google killing every token weekly is a free, repeating, realistic failure injection on real connectors โ€” it becomes a canary once something watches it. Related: ADR-135 ยง3.4 rules a per-tenant STALE verdict that overlaps this ground from the score side โ€” reconcile, don't build twice.

Ordering

Why is it in this order?

The track is deferred, so the criterion collapses to one rule: pick up the single open item, connector-liveness. It is the only open issue on the label and the only priority p1 โ€” and it survives the deferral precisely because killing the score did not kill it.

  • It ignores the tenant-health score โ€” the composite is deferred and drives nothing; nothing branches on composite_score across backend, platform or client.
  • It ignores the ratio fix โ€” a four-expert panel killed the proposed ratio fix, and the standing instruction is not to resume by building it.
  • It ignores issue age, filing order and fix size โ€” with one open issue, none of those axes can re-order the list.
  • It ignores the metrics the score computed โ€” those are the deferred artifact, not the open work.

Standing rulings

History

Why the score was deferred

The tenant-health score was deferred by the owner after a four-expert panel killed both the shipped composite and the proposed ratio fix โ€” so the track's live surface is a single item: connector-liveness, which survives because it is not a measurement problem. This page has never been published.