A customer writes "checkout is broken for me" and you can't tell whether it's their card, your code or a provider outage. That gap, between "it works on my machine" and "I know it works in production", is what observability closes. A first action that takes an hour: generate one request ID at the edge, put it in every log line and return it in a response header, so any bug report can be traced to exact server events.
This is a supporting guide under the SaaS Backend Infrastructure pillar. If you've shipped an MVP and now have real users, it walks through what to log, which metrics to watch, how traces tie them together and how to build alerts you won't learn to ignore.
What is SaaS monitoring, and how is it different from logging and observability?
SaaS monitoring means watching known metrics against thresholds you chose in advance, while observability is the wider ability to ask new questions of your system from telemetry you already collect, without shipping new code.
OpenTelemetry's signals documentation (checked 30 September 2026) defines the building blocks: traces are the path of a request through your application, metrics are a measurement captured at runtime, and logs are a recording of an event. Logging records discrete events, such as a request coming in, a payment failing or a webhook being retried. Monitoring asks whether the thing you expected to break is broken. Observability asks why one specific tenant is seeing 500s that nobody else is. Monitoring catches the failures you predicted, and observability is what you need for the one you didn't.
What should you actually log in a SaaS app?
Enough to reconstruct an incident, not so much that you drown. A useful default per request:
- Inbound request: method, path,
tenantId, authenticated user ID andrequestId. - Outbound calls: every call to Stripe, your database or an email provider, with duration and outcome.
- Errors: the full stack trace, the triggering input with secrets redacted, and the
requestId. - Business events: subscription created, plan upgraded, tenant signed up. These double as a cheap product-analytics stream.
Don't log raw passwords, full card numbers, API keys or personal data you don't need, and redact at the logging layer rather than after the fact. Structured JSON also lets you filter millions of lines in seconds with a query like level=error AND tenantId=abc123, which plain string logs can't do. Here's one line as an example:
{ "level": "error", "ts": "2026-09-30T10:12:03Z", "tenantId": "tenant_42", "requestId": "req_8f3a", "msg": "stripe charge failed", "code": "card_declined" }
That single line answers four questions a bare console.log("charge failed") can't: which tenant, which request, which provider call and which failure code.
On Callidus, the clinic SaaS I built on React and Firebase, data lives under tenants/{tenantId}/… in Firestore and JWT claims carry tenantId and role. The same field that gates data access is the natural correlation key for logs. Your tenancy boundary and your observability dimension should be one field, and the multi-tenant SaaS architecture guide covers the isolation side.
Which metrics matter for a SaaS backend?
Start with the four golden signals from the Google SRE book chapter on monitoring distributed systems (checked 30 September 2026): latency, traffic, errors and saturation. It defines latency as the time it takes to service a request, traffic as how much demand is placed on your system, errors as the rate of requests that fail, and saturation as how "full" your service is.
- Latency: track percentiles (p50, p95, p99), not averages. The book's example is a service with 100 ms average latency at 1,000 requests per second, where 1% of requests might easily take 5 seconds.
- Traffic: requests per second, so you can tell an outage from a quiet Sunday.
- Errors: a rate against traffic, split by endpoint and ideally by tenant.
- Saturation: database connections, function concurrency, queue depth.
Then add business metrics: signups per day, failed payments, webhook retry rate and background-job backlog. A spike in failed payments is a billing bug before it's a CPU graph. If background work is a big part of your app, give queue depth and retries their own dashboard; the processing side is in background jobs for SaaS, and the failure side is in webhook reliability, idempotency and dead-letter queues.
How do traces and correlation IDs tie logs and metrics together?
A trace follows one request through every service it touches and records the timing of each hop, and a correlation ID is the lightweight version: one identifier generated at the edge and attached to every downstream call and log line.
When checkout is slow, a trace shows whether the time went to your database, Stripe or your own code, instead of you bisecting logs by hand. You don't need a full tracing vendor on day one. Carry the same ID into background jobs and webhook handlers, for example by storing it on the job payload, so the trail doesn't stop at the queue. Keep field names identical across services too, so one query works everywhere. One ID per request, included in every log line, turns "show me everything that happened for req_8f3a" into a single filter. When you're ready for real distributed tracing, the W3C Trace Context recommendation (published 23 November 2021) standardizes a traceparent header made of a version, a 16-byte trace ID, an 8-byte parent ID and trace flags, so services from different vendors can continue the same trace.
Consider a hypothetical bug report from a macOS user and the same bug from an Android user. BookBed ships to iOS, Android, Web, macOS, Linux and Windows from one Flutter codebase, so both reports share a code path. A request ID generated on the client and sent with each call, which is my recommendation rather than something the case study documents, would let you connect a client-side report to the exact server request that failed. Without correlation, cross-platform bug reports are guesswork.
What makes an alert good, and which tools should a small SaaS start with?
A good alert detects something urgent, actionable and user-visible, and a small SaaS should start with the logs and dashboards its platform already provides before adding any hosted tool.
How do you avoid alert fatigue?
The Google SRE book asks of every paging rule whether it detects an otherwise undetected condition that is urgent, actionable and actively or imminently user-visible, and says every page should be actionable. The problem is common. In the Grafana Labs Observability Survey 2026 (1,363 respondents, collected October 2025 to January 2026), 30% named alert fatigue as their primary obstacle to faster incident response and 34% struggled with signal-to-noise. Translating that into rules for a small team:
- Alert on symptoms users feel. "Login error rate above 5%" is actionable. "Memory at 70%" usually isn't.
- Require duration. "Above threshold for five minutes" filters a one-second blip.
- Tier by severity. A checkout outage pages someone. A nightly job running slow can wait until morning.
- Delete flaky alerts. One false page erodes trust in all of them.
- Name an owner and a first step. Write down who receives each alert and what they should check first; an alert with no owner is really a dashboard.
A starting set for a small SaaS is four alerts: error rate on your top three endpoints, payment failures, an external uptime check and a background-job backlog. Those four cover the failures that lose customers.
Which tools should you start with?
The platform's own tooling first. Vercel provides build logs, runtime logs and log drains for exporting data, and says runtime log retention depends on your plan. Supabase's Logs Explorer exposes API Gateway, Postgres, Auth, Storage, PostgREST, Edge Function, Realtime and pooler events, again with retention that depends on the plan. Check the current limits on those pages before you rely on them for incident review.
The progression I'd follow is: platform logs, then an error tracker once you have paying users, then a log-search tool when grepping becomes painful, and self-hosted observability only when cost or data residency forces it. Sentry, Axiom, Grafana Cloud and Better Stack are the usual names, and the Sentry vs Datadog vs Honeycomb comparison weighs the trade-offs with current details. Privacy settings matter as much as features: Callidus runs Sentry in a strict GDPR mode with sendDefaultPii: false and Replay masking all text, blocking all media and masking all inputs. The same buy-the-defaults-first logic applies to hosting, as in multi-region SaaS deployment: when and how.
Here's a concrete next step. Pick your most valuable endpoint, add the request ID and tenantId to its logs, and write the one alert that would tell you it's failing for users. Which tenant would be the first to hit it, and would you find out before they write to you?