Observability vs Monitoring vs Logging: What's the Difference?

These three terms get used interchangeably, but they solve different problems. Understanding the difference helps you build the right tooling stack without buying more than you need.

The Short Version

Logging — records what happened (events and context)
Monitoring — watches known metrics and alerts when they go wrong
Observability — the ability to understand what's happening inside a system from its external outputs

They're not competitors. They're layers.

Logging: The Foundation

Logging is the act of recording events from your application. Every HTTP request, every error, every state change can produce a log entry:

{
  "timestamp": "2026-08-20T14:23:11Z",
  "level": "error",
  "service": "payment-api",
  "message": "charge.failed",
  "user_id": 42,
  "error": "card_declined",
  "amount": 99.00,
  "trace_id": "abc-123"
}

Logs are the raw evidence. They answer: what happened, when, and in what context?

Good logging practices:

Structured JSON output (not plain text)
Correct log levels (debug, info, warn, error)
Context fields (user ID, request ID, trace ID)
Centralized collection (not scattered across servers)

Without logs, you have no evidence to investigate. They're the input to everything else.

Monitoring: Watching Known Metrics

Monitoring means collecting numeric metrics and alerting when they cross thresholds you've defined:

CPU usage > 90% for 5 minutes → alert
Error rate > 5% → alert
Response time p99 > 2 seconds → alert
Disk usage > 85% → alert

Monitoring answers: is something wrong right now?

It's reactive and threshold-based. You decide in advance what "wrong" looks like, set a number, and wait for the alert. This works well for known failure modes — the problems you've seen before and can define in advance.

The limitation: monitoring can only watch things you thought to measure. It catches known problems, not unknown ones.

Observability: Understanding Why

Observability is the ability to ask new questions about your system without deploying new code. It answers: why is this happening?

When monitoring says "error rate is 12%", observability lets you dig in:

Which service is producing the errors?
Did it start after a deploy? (deployment markers)
Is it one user or all users?
What does the request path look like? (trace correlation)
Is it correlated with a spike in another service? (service map)

Observability requires three types of data (the "three pillars"):

1. Logs — Event-Level Detail

Individual events with full context. The most granular data type. You search logs when you need to understand a specific failure.

2. Metrics — Aggregated Numbers

Time-series data: request count, error rate, latency percentiles, queue depth. Cheap to store, fast to query, good for dashboards and alerts. But metrics lose individual event context — you know the error rate is 12%, but not which errors.

3. Traces — Request Paths

A trace follows a single request across multiple services. Each service adds a "span" with timing data. Traces answer "where did the time go?" and "which service caused the failure?"

How They Work Together

Here's a realistic debugging session:

Monitoring alert: "Error rate on api service exceeded 5%" (Slack notification)
Dashboard: Check the error rate chart — spike started 10 minutes ago
Deployment markers: A deploy happened 12 minutes ago — probably related
Log search: level:error service:api → 300 errors, all "connection refused" to the payment service
Trace correlation: Click a trace ID → request reached payment-api but got no response
Root cause: The deploy changed the payment service URL but the API service still has the old config cached

Without logs, you know something is wrong but can't see the actual errors. Without monitoring, you don't know something is wrong until a user reports it. Without the ability to query and correlate (observability), you can't connect the deploy to the errors.

What Do You Actually Need?

Every team needs logging

Even a solo developer needs to know what happened when something breaks. Centralized logging with search and basic alerts covers most needs. This is where most teams should start.

Add monitoring when you have SLOs

When you have uptime targets, response time goals, or error budgets, monitoring gives you the dashboards and alerts to track them.

Add full observability when debugging gets slow

When "find and fix a production issue" takes hours instead of minutes, invest in trace correlation, service maps, and cross-service search. This typically happens when you have 5+ services.

The Practical Stack

You don't need three separate tools. Modern log management platforms combine all three:

Need	LogFlow Feature
Logging	Log search + live tail
Monitoring	Alerts + anomaly detection
Observability	Trace correlation + service map + dashboards

Start with logs. Add alerts. Layer in traces and service maps as your architecture grows. You don't need to buy the full observability platform on day one.