Observability

The three pillars

• Logs. Time-stamped text events. Used for individual-event debugging. "What did this request see?"
• Metrics. Aggregated numerical measurements. Used for trends and alerting. "How many requests/sec? P99 latency?"
• Traces. End-to-end request tracking across services. Used for performance debugging in distributed systems. "Where did the 4-second response time go?"

Real observability needs all three. You can debug one outage without traces if your system is simple enough — but you'll waste hours on each new outage that you could have spent shipping.

What most early-stage teams ship

Console.log statements scattered through the code. No structured logging. No metrics. Errors caught by Sentry (one of the few things teams actually wire up). When something breaks at 50 users, the founder spends a day understanding why.

What good looks like at MVP scale

Cheap, easy stack we ship with most MVPs:

• Logs: structured JSON to stdout, captured by Vercel/Railway/your platform
• Metrics: Vercel Analytics or PostHog for product, platform metrics for infra
• Errors: Sentry from day one
• Tracing: skip until you have a distributed system or async pipelines
• Performance: Speed Insights or platform-native

Cost: $0–$50/month at MVP scale. Adding this on day one is much cheaper than retrofitting it after the first outage.

What you don't need at v1

• Datadog, Honeycomb, or other enterprise APM platforms (overkill until you have $10K+/month of revenue per app)
• Custom Grafana dashboards (most platforms have built-in dashboards good enough)
• Multi-cloud observability (until you're multi-cloud, which usually you aren't)

What you do need from day one

A way to query historical logs (not just current tail). Errors aggregated and de-duplicated. The four golden signals: latency, traffic, errors, saturation. Without these you're flying blind.

Related