Observability
Being able to answer 'why is it broken?' from the data your app already emits, without shipping new code just to find out.
See it
What it is
Observability is the property of being able to answer new questions about a running system using only the data it already emits. The three classic signals are logs (what happened), metrics (how much, how often), and traces (where the time went). Monitoring answers questions you thought of in advance; observability is what you need for the ones you didn't.
Reach for it the moment a bug survives a page refresh on someone else's machine. If your debugging move is 'add a console.log and redeploy', you have no observability, you have a slot machine. The practical minimum for a small app: structured JSON logs with a correlation ID, error tracking, and the four golden signals (latency, traffic, errors, saturation) on one dashboard.
Gotcha: buying a tool does not buy you the property. Vendors sell dashboards, but you only get answers if your telemetry carries the context you will want to slice by, such as user, tenant, route, and release. The flip side is cost: those same high-cardinality fields are exactly what blows up the bill, so decide what you keep before the invoice decides for you.
Ask AI for it
Set up observability for this app end to end. Emit structured JSON logs with a per-request correlation ID, record RED metrics (request rate, error rate, duration) per route, and create traces around every outbound HTTP call, database query, and background job. Instrument with OpenTelemetry and export over OTLP so the backend is swappable. Add a /healthz endpoint, wire an error tracker for uncaught exceptions, and tag every signal with service name, environment, and release SHA. Do not log passwords, tokens, or email addresses.