How to Set Up Observability Before You Have Users

When to Use This

You are building your product and you are tempted to skip monitoring until you "have real users." This guide explains why that is a mistake and how to set up a solid foundation in under a day.

Why This Matters

Observability is one of those things that feels optional until something breaks in production and you have no idea why. By then, adding it properly is twice as hard — you are doing it under pressure, with incomplete context, while users are affected.

The right time to set up observability is before your first user. The Observability Ladder runs: Logs → Metrics → Tracing → Business Observability. For an early-stage product, you need the first two confidently before you worry about the others.

Step 1: Structured Logging

Do not use print statements or unformatted log strings. Use structured logs from day one.

What structured logging looks like:

{
  "timestamp": "2026-07-10T09:15:22Z",
  "level": "error",
  "service": "api",
  "user_id": "usr_123",
  "endpoint": "/api/orders",
  "error": "Database connection timeout",
  "duration_ms": 5043
}

Every log entry should answer: what happened, when, where, and who was affected. JSON format means you can query and filter logs programmatically.

Tools: Winston (Node.js), structlog (Python), zerolog (Go). All free.

Step 2: Application Error Tracking

Before you worry about infrastructure metrics, make sure you are capturing every unhandled error in your application. Sentry is the standard here. Free tier is sufficient for early stage. Set it up in an afternoon.

It will capture stack traces, user context, and error frequency — everything you need to prioritise what to fix.

Step 3: Uptime Monitoring

Set up a simple uptime check that pings your API every minute and alerts you if it does not respond. Better Uptime, UptimeRobot, or Freshping all have free tiers.

This is the minimum viable monitoring: you find out about outages before your users do.

Step 4: Basic Metrics

Add three metrics to start:

• Request rate — how many requests per minute is your API handling?
• Error rate — what percentage of requests are failing?
• Latency (p95) — what does the 95th percentile response time look like?

These three numbers tell you almost everything about your application health at a glance. Tools: Datadog, Grafana Cloud, or CloudWatch. All have free or low-cost tiers for early-stage usage.

Step 5: Add a Health Endpoint

Add a /health endpoint to your API that returns application status and basic system information. This is what your uptime monitor pings, and what a new engineer checks first when something is wrong.

Step 6: Set Up Alerting

Configure at minimum:

• Alert when error rate exceeds 1% over a 5-minute window
• Alert when p95 latency exceeds your defined threshold
• Alert when the service is unreachable for more than 2 minutes

Send alerts to Slack or email. On-call paging tools are overkill at seed.

Common Mistakes

Adding logging as an afterthought

If you add observability after a production incident, you will add it reactively — which means you will add the bits that would have helped with that specific incident, not the bits that help with the next one.

Verbose logging in production

Logging every database query at DEBUG level in production will spike your log storage costs and destroy signal-to-noise ratio. Set production logging to INFO level by default.

Not including user context in logs

"Database error" is far less useful than "Database error for user usr_123 on checkout endpoint." Always include user and request context in error logs.

Summary

Observability before users means you understand your system before it is under pressure. Start with logs and error tracking, add basic metrics, add distributed tracing when you are diagnosing multi-service issues. Build the foundation first — the Observability Ladder gives you the sequence.