My dashboard took 45 seconds to load — pos_sync_queue had 287k + qr_scan_events 1.8M rows, prune cron missing

Lorenzo (41) runs Trattoria del Porto in Vernazza, Cinque Terre — 28 covers + 8 guest rooms, on thMenu Diamond for 2 years. Saturday after the season opened the Reports page took 45-50 seconds blank, POS sync to Square delayed 2-3 minutes, QR scan analytics timed out at 60s. thMenu support 4-layer forensic: D1 quota throttle? 3M/month reads is well under cap. Regional outage? Edges healthy. Tier downgrade? Diamond active. Real cause: D1 query latency. pos_sync_queue COUNT(*) 12.4s, qr_scan_events GROUP BY 33s, JOIN query 28s. Table sizes: pos_sync_queue 287,184 rows (251k success + 35k dead). qr_scan_events 1,847,692 rows (>1M older than 12mo). auto-prune.ts had pruneOldOrders + pruneOldFeedback + etc — prunePosSyncQueue + pruneQrScanEvents MISSING since launch (migrations 0027 + 0039 shipped late 2024 with no prune partner). **PR #660 batch X F5** fix: two new cron jobs — prunePosSyncQueue (90d retention, status IN success/dead) + pruneQrScanEvents (12mo retention). Wired into cloudflare/src/index.ts 04:00 UTC dispatcher slot with idempotent BATCH_SIZE=1000 loop. Plus two entries added to migration-drift-check.ts EXPECTED_TABLES: pw_failures (0076) + ai_quota_usage (0079) — fresh deploy that skips either migration triggers Sentry alert. Lorenzo s account got a manual backfill that evening; Sunday morning Reports loaded in 1.2s, POS sync delay dropped to 200ms, QR analytics to 600ms. Pattern: every new D1 table migration — especially write-heavy log/event/queue/history tables — must ship with auto-prune function + cron scheduling + drift-check entry in the SAME PR. Deferred prune guarantees gradual dashboard slowdown, high-volume operators first, low-volume in 5-10 years.

Related articles