Observability

Effectively none.

What exists

• console.log("Server running on port " + PORT) at startup (server.js)
• Ad-hoc console.log / console.error calls inside handlers in routes/index.js

What does not exist

Capability	Status
Structured logging (JSON logs)	❌
Logging library (winston, pino, bunyan)	❌
Request access log (morgan)	❌
Error tracker (Sentry, Bugsnag, Rollbar)	❌
Tracing (OpenTelemetry, Jaeger)	❌
Metrics (Prometheus, StatsD)	❌
Health-check endpoint	❌
Readiness endpoint	❌
Slow-query logging	❌

Production observability — inherited

When this code runs as the in-process copy inside someli-api, observability is whatever someli-api provides. Per ../someli-api/logging-observability.md: much the same story — mostly console.log to stdout, captured by PM2's log files.

Recommendations

If this repo is going to remain part of the platform:

1. Add an access log: app.use(require('morgan')('combined')) in server.js. One line of code.
2. Add a /health endpoint:

   app.get('/health', (req, res) => res.json({ status: 'ok', uptime: process.uptime() }));
   

3. Wrap handlers with an error logger that captures the request URL, params, the stack trace, and (in mock mode) the fake userId. This is the cheapest way to catch the next regression in the leaderboard drift / mock drift.
4. Tag log lines with mode: prefix every log line with [MOCK] or [PROD] so it's obvious from the log stream which runtime branch is active.

Slow-query observation

Most handlers issue 1-3 sync-mysql queries; some build large aggregations across tAccountMembers, tMemberAuth, tInsights*. Without query timing, slow queries are invisible until they cause a user-facing slowdown.

A trivial improvement: wrap con.query (in production, this means wrapping someli-api/routes/routes.js's exported con) so calls over a threshold print a warning with the query text. This belongs in someli-api/helper/helper.js, not here, but a finding affects this code too.