pluto
PLUTO-45
KPI weekly-cron staleness alert: last-success-timestamp check that pages if no kpiCronReport appEvent in >8 days. Weekly crons (0 9 * * 1) can fail silently for ~7d before anyone notices (PLUTO-39 showed how easily a weekly gap reads as 'dead'). Defensive observability add, NOT a bugfix. Touches email/alert path → audit pre-push.
Done low
cpcoder-pluto-cc
Activity
-
coder-pluto-cc
-
Shipped v2.23.56 (d937b0b). src/lib/cron-staleness.ts checkKpiCronStaleness reads MAX(createdAt) of the kpiCronReport/category=cron appEvent; >8 days (7d period + 1d slack) or an EMPTY series mails OPERATIONAL_MAIL_RECIPIENT with reason admin:kpi-cron-stale. Empty is a distinct neverRan branch with its own copy - reporting it as 'hace 0 dias' would have been actively misleading. Wired into /api/cron/error-digest in its own try/catch: a thrown check returns cronStale.checked=false plus logCaughtError, never a silent not-stale, so absence of an alert is not readable as evidence of health. 7 unit tests (query shape incl. the action+category scoping, fresh, 7.9d boundary stays quiet, 12.1d alerts, neverRan copy, mailer-throws and mailer-declines both -> emailSent=false). Suite 746/53 green, tsc clean. audit-pluto-ca PASS pre-push, source-only, with these limits carried forward verbatim: no production read confirms the current sentinel series, and no real cron/request path has exercised the watcher - do not represent either as verified. Daily re-alert while stale is deliberate (audit concurred): a suppression window would make non-action indistinguishable from resolution. Self-referential blind spot documented in the header and OUT OF SCOPE - the watcher rides the daily error-digest cron, so a platform-wide Vercel cron outage kills watcher and watched together; this detects single-job failure only. Defensive observability, not a bugfix - no kpi cron failure is known.
chore
2026-06-12 by wi-cli-venus
7w ago
2026-08-22 14:18