What to Log in a SaaS Product Before You Need It

Every logging strategy is fine right up until the first outage, when you find out you logged the wrong things and none of the right ones. What to log in a SaaS product is one of those decisions that seems trivial until it isn't — and the cost of getting it wrong is measured in customer trust and 3am reconstructions.

Here's the shape we default to on projects.

The three questions logs need to answer

When something breaks, three questions come up:

1. What did the user try to do?
2. What did the system actually do?
3. Why did those two things not match?

If your logs answer these, you're in good shape. If they don't, you're guessing.

What to log

Every request boundary

Method, path, user ID, request ID, status code, latency. This is the skeleton. Every other log line connects to a request via the request ID.

Every outbound call

Third-party API calls, database queries that matter, model calls. Timing, status, and enough of the request to reconstruct — not the full payload if it contains user data.

State transitions

Subscription created, subscription cancelled, job queued, job completed, job failed. Anything that would appear on a timeline when a customer asks "what happened to my account?"

Failures with context

Every error gets logged with the request ID, the user ID, and the specific state that led to it. "Payment failed" is useless. "Payment failed for user 123, invoice 456, Stripe error card_declined" is useful.

Security-sensitive events

Logins, password resets, permission changes, API key usage. Never log the credential itself.

What to drop

Successful reads

Logging every successful GET is expensive and adds no debugging value. Sample it — 1% is plenty. Related reading: Error tracking for small SaaS.

Chatter from libraries

ORMs, HTTP clients, and cloud SDKs are chatty at info level. Set them to warn by default.

Personally identifiable information

Emails, names, addresses, payment details — never log these directly. Hash or truncate if you need to correlate. Related reading: Handling PII in AI applications.

Full request bodies

Log the shape (keys present, sizes) not the contents. Bodies balloon log volume and often contain user data.

Structured, not stringy

Every log line is a JSON object. Timestamp, level, message, plus a flat set of tags. This lets you search "all failures for user X in the last hour" without regex acrobatics.

{
  "ts": "2027-10-02T14:32:11Z",
  "level": "error",
  "msg": "payment_failed",
  "request_id": "req_abc",
  "user_id": "usr_123",
  "stripe_code": "card_declined",
  "amount": 4900
}

Message is a stable event name, not a sentence. This lets you count events cleanly.

Log levels that actually mean something

• Error: something failed and a user or process is affected.
• Warn: something is off but the system recovered.
• Info: state transitions and business events.
• Debug: verbose detail, off in production by default.

The mistake we see: everything logged at info because "we might need it." Then production runs at 500MB/hour of noise and no one can find anything.

Cost control

Log cost grows quadratically with success. More users → more requests → more logs → more indexing. Three levers:

Sampling

Keep 100% of errors and warns. Sample info at 10-25%. Debug is off in production.

Retention

Hot storage for 7-14 days. Cold storage or nothing beyond 30 days for most events. Security-sensitive events keep for longer, compliance permitting.

Cardinality

Watch high-cardinality fields. A tag like user_id is fine. A tag like full_url with query params explodes the index. Structure your log fields to keep unique-value counts bounded.

Traces beat logs for request flows

For requests that fan out to multiple services or async jobs, distributed tracing (OpenTelemetry, Datadog APM, Honeycomb) beats grep-through-logs. You still keep logs for events; you use traces for "why did this one request take 12 seconds?"

Where to send it

For early-stage SaaS: pick a hosted service. Axiom, Baselime, Better Stack, Honeycomb, Datadog. The engineering time to run Grafana + Loki + Tempo yourself is not worth it under $500/month of log spend.

The tool matters less than having a tool with structured logs, decent search, and alerting.

Alerting off logs

Two kinds of alerts:

• Threshold: "error rate above 1% for 5 minutes."
• Anomaly: "sudden spike in payment_failed."

Start with thresholds. Anomaly detection is worth the setup only after you have baseline data to detect anomalies against.

Common misconceptions

"More logs = more visibility." Only up to a point. Past that, more logs = more noise = worse visibility.

"Logs replace metrics." They don't. Metrics (RED, USE) show system health at a glance. Logs give you the story.

"We'll add logging when we need it." You need it during an outage, when adding it is too late.

FAQ

Should I log to a file or straight to the service?

Straight to the service, via the platform's log drain. Files are extra hops that fail at bad times.

How do I log across serverless boundaries?

Include a request ID in every downstream call. Have the downstream include it in its logs. Related reading: Long-running jobs in serverless.

What about GDPR?

Logs count as data. Retention limits apply to any user-identifying data in them. Set retention short and mask PII by default.

Where to go from here

If you're not sure your current logs would survive an outage-time investigation, spend an afternoon simulating one — pick a customer, try to reconstruct their session. The gaps will be obvious. Our SaaS and web apps engagements often start with exactly this exercise.