What is observability?

Why should observability catch failures before customers do?

In a prototype, you find out something is broken because you are the one clicking. In production, your users find out first, and most of them do not tell you: they leave. The first job of observability is to make sure you hear about a failure before a customer has to report it.

What observability does a new app need on day one?

A new app needs four things on day one: error tracking that captures each unhandled error with context, uptime and health checks that test the database as well as the server, structured logs you can search by user, request and time, and alerts that reach a person on a few signals that matter.

• Error tracking: every unhandled error captured with the context to reproduce it.
• Uptime and health checks that test the database answers, not only that the server is up.
• Structured logs you can search by user, request and time.
• Alerts that go to a person, on a small number of signals that matter.

What are logs, metrics and traces?

They are the three kinds of data a system emits, and each answers a different question. OpenTelemetry, the open standard most tools now follow, defines a log as a timestamped message from a service, a metric as an aggregation of numeric data over a period of time, and a trace as the path of one request across services.

• Logs say what happened: a payment failed for this user at this time. On their own they often lack context, which is why the primer recommends tying them to a trace.
• Metrics say how much and how often: the error rate rose from 0.1% to 4% in five minutes. They are cheap to keep and good for alerts.
• Traces say where the time went. A trace is built from spans, one per unit of work, each with a name, timing and attributes, so a slow checkout can be pinned to the one database query that caused it.

How do you add observability to a Lovable or Supabase app?

Start with what Supabase already records. Its dashboard has a Logs page that filters by source, including the API gateway, Postgres, Auth, Storage, Edge Functions and Realtime, and by level, status, path or user. Each row opens to its raw JSON.

How long logs are kept depends on your plan, so do not treat them as an archive. Then add what Supabase cannot see: errors in the browser, a health check that queries the database, and an alert on a few signals. Our production readiness check asks whether each of these is in place.

What mistakes make observability useless when you need it?

Observability fails in predictable ways: free-text logs you cannot filter, logs that hold secrets or personal data, averages that hide the users who wait longest, checks on a system that is up but wrong, and alerts nobody owns. Each one leaves you without an answer at the moment you need it.

• Unstructured logs: free text you cannot filter by user or request.
• Logging secrets or personal data, which turns the log into a liability.
• Watching averages. A metric can look healthy while a slice of users waits far longer, so track a high percentile too.
• A system that is up but wrong. The OpenTelemetry primer notes that a service can be up all the time and still be unreliable, because reliability is whether it does what users expect.
• Alerts nobody owns, which teach the team to ignore them.

What does observability look like on a real product?

On a real product, observability turns a future question, what failed and why, into a lookup instead of an investigation: probes that catch a broken flow, stored records of failed payments, and a log of every operator action. None of it is visible to a reader, and none of it exists in a prototype.

If your app has none of this yet, our vibe coding rescue adds it, and the plans cover running it afterwards.