Observability starts with the user, not the dashboard

It is easy to wire up a dashboard full of CPU, memory, and request counts and call it observability. That tells you whether your box is healthy, but it does not tell you whether your user is having a bad time. Those are different questions, and the second one is the one your business cares about.

Answer the user's question first

Before anything else, pick the one path that matters most, usually the sign-up or the checkout, and instrument it end to end. Measure how long it takes, how often it fails, and where it gets stuck. Every other metric is downstream of those three numbers.

Instrument the journey, not just the box

• Carry a trace ID through every hop so a single request can be followed from the client to the database.
• Log errors with the context around them, the user, the operation, and the input, not a bare message.
• Track latency on the real user paths, and alert on the slow ones before they become the failing ones.

// An error log that can actually be acted on
log.error("payment_failed", {
  traceId: req.headers["x-trace-id"],
  userId: req.user.id,
  operation: "checkout.pay",
  provider: "stripe",
  httpStatus: 402,
  elapsedMs: 843,
});

When your dashboard starts with the user and works backward, an alert stops being noise and starts being a specific, debuggable event. That is the difference between a graph and an answer.