Application monitoring โ
- Status: in progress, opened 2026-08-27. Server-side error surfacing and uptime landed the same day; client-side capture is not started.
- Issue:
#164: Infra: Application Monitoring & Observability - Launch plan:
ALPHA.mdPhase 2: Ready, row "Devops hardening". The row already carries#164, so no launch-plan edit was made. (Was Phase 4 before the 2026-08-31 timeline shift renumbered Alpha's phases.)
What is this? โ
Knowing when Lantern is broken, without a person having to notice first. โ
- Covers error capture, uptime, and the alerting on top of them.
#164scopes the whole area: error tracking, performance monitoring, structured logging and tracing, and dashboards. - It exists because the System Health page reported green while things were failing. On 2026-08-27 its Errors tab said "No errors logged" while the nightly aggregation job had been 404ing for days, and its Uptime tab checked four URLs of which three could never have passed.
This is a deliverable area, not one task. โ
- Sequenced work lives in
planning.md. Unsequenced ideas live inbacklog.md. - The first unstarted task is client-side error capture, which is the largest remaining hole.
What is the current state? โ
Server-side errors are now visible, and they were not before. โ
- The Errors tab reads Cloud Logging for
severity>=ERRORviagetServerErrorsMetricsinsystemHealth.service.js, grouped by source with a recent feed. - It found 34 errors in 7 days across 5 sources on a tab that reported none.
- The old panel read the
clientErrorsFirestore collection, which holds zero documents and has never had a writer. That is why it always said "No errors logged".
Uptime covers the real surface now. โ
- Nine endpoints (two frontends plus the seven registered APIs), derived from
packages/shared/servicesso a new service is monitored the day it is registered. - Was four endpoints, of which three pointed at hosts that do not resolve or a bot with no HTTP listener.
Cloud Error Reporting is already running and has never been surfaced. โ
- It is enabled on
lantern-app-devand already groups errors by signature withresolutionStatus,firstSeenTime,lastSeenTimeandcount. Five groups are OPEN, the oldest first seen 2026-01-30. - It answers "is this error resolved", which Cloud Logging cannot. Surfacing it is a sequenced task.
Nothing captures client errors at all. โ
- No
window.onerror, nounhandledrejectionhandler, no Sentry, in either app. - The admin portal's single
ErrorBoundaryonly callsconsole.error. The web PWA has no boundary at all. - A user hitting a crash produces nothing anyone can see. This is the next task.
What else is related? โ
#164: Infra: Application Monitoring & Observability, the canonical issue. Consolidation found no other open issue covering error tracking, so none was filed.merchant-and-venue-dashboards, where the 2026-08-27 System Health work is recorded, since it came out of that task's nav rearrange.- The deleted
analytics-daily-aggregationCloud Scheduler job, whose nightly 404s were 20 of the 34 errors. Its route was retired in the#616cleanup and the job was never deleted alongside it.