Monitoring a SaaS application: best practices explained

By day 69 of building a robust observability foundation, you've instrumented individual services and learned how to alert on anomalies. But monitoring a SaaS application: best practices explained goes much further—it requires a holistic view spanning edge infrastructure, service internals, data layer health, and business outcomes. Without this layered approach, you'll miss the early warning signs that lead to customer churn and revenue loss.

Edge — Uptime probes and TLS expiry

Your SaaS application lives at the edge before it reaches your servers. Users hit a CDN, a load balancer, or a DNS resolver. Monitoring this layer means answering the question: can customers even reach you? Uptime probes from multiple geographic regions give you that answer in real time.

Set up synthetic HTTP requests that exercise your critical user paths—login, API authentication, core workflows. Use Prometheus's Blackbox Exporter to probe endpoints every 30 seconds from different continents. When a probe fails, you know users in that region are affected before your support queue fills up.

global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'blackbox-http'
    metrics_path: /probe
    params:
      module: [http_2xx]
    static_configs:
      - targets:
        - https://api.example.com/health
        - https://example.com/login
        - https://cdn.example.com/assets/app.js
    relabel_configs:
      - source_labels: [__address__]
        target_label: __param_target
      - source_labels: [__param_target]
        target_label: instance
      - target_label: __address__
        replacement: blackbox-exporter:9115

Equally critical: TLS certificate expiry. A forgotten renewal is a guaranteed outage. Blackbox Exporter also exposes probe_ssl_earliest_cert_expiry, which tells you exactly when your certificates expire. Alert when that timestamp is less than 14 days away, and your ops team renews the cert before customers see a browser warning.

- alert: CertificateExpiryWarning
  expr: (probe_ssl_earliest_cert_expiry - time()) / 86400 < 14
  for: 1h
  annotations:
    summary: "Certificate expiring in {{ $value | humanize }}d"

Services — RED metrics per API

RED stands for Rate, Errors, and Duration—the trinity of service health. For a SaaS application, you instrument each API endpoint to emit these three signals. This is where you catch slow queries, cascading failures, and code regressions the instant they land in production.

Let's say you're running a NestJS backend. Use Prometheus client middleware to record latency buckets, error counts, and request counts per endpoint and HTTP method.

http_requests_total{job="api",method="POST",endpoint="/api/users",status="201"} 1523
http_requests_total{job="api",method="POST",endpoint="/api/users",status="500"} 12
http_request_duration_seconds_bucket{job="api",endpoint="/api/users",le="0.1"} 1400
http_request_duration_seconds_bucket{job="api",endpoint="/api/users",le="1.0"} 1510
http_request_duration_seconds_bucket{job="api",endpoint="/api/users",le="5.0"} 1520

In Grafana, graph the error rate and p95 latency per endpoint. When signup POST requests suddenly spike from 50ms to 2 seconds, you spot it immediately. Team members investigating that endpoint have concrete data: "The database query for user creation got slower, not our code."

Most teams make the mistake of a single "api-latency" metric. You need per-endpoint granularity, because a slow endpoint at 1% of traffic might not trigger an overall threshold alert, yet it's degrading your conversion funnel.

Data — Database, cache and queue health

Your service metrics tell you if requests are fast, but they don't explain why. Nine times out of ten, slowness originates in the data layer: a PostgreSQL query plan regressed, Redis evicted keys under memory pressure, or Kafka lag grew because consumers are backed up.

For PostgreSQL, use the official Prometheus exporter to scrape system catalogs. Key metrics include active connections, cache hit ratio, and transaction rate.

pg_stat_database_blks_hit / (pg_stat_database_blks_hit + pg_stat_database_blks_read) as cache_hit_ratio
pg_stat_activity_count{state="active"}
pg_stat_user_tables_live_tuples  # row count

When cache_hit_ratio dips below 95%, your database is doing more disk I/O than it should. That's your cue to investigate missing indexes or a query that got slower. Active connections creeping toward your max_connections limit signals a connection leak in one of your services.

For Redis, monitor memory usage, evicted keys, and command latency. If evicted_keys_total is rising, your application is asking Redis to store more than it can hold. Either increase memory, or you're storing the wrong data there.

For Kafka or any message queue, track consumer lag per topic and partition. If lag is growing, consumers can't keep up with producers. That means downstream jobs—email sends, payment processing, analytics—are falling behind. Alert when lag for critical topics crosses a threshold (e.g., 10,000 messages).

- alert: KafkaConsumerLagHigh
  expr: kafka_consumer_lag{topic="payment_events"} > 10000
  for: 5m
  annotations:
    summary: "{{ $labels.group }} lagging by {{ $value }} messages"

Business — Signups and payment success rates

Technical metrics tell you the system is working. Business metrics tell you the system is working for revenue. A SaaS application can have perfect uptime and fast APIs while users churn because signups fail silently or payment processing drops.

Instrument signup flows to emit a counter when a user completes each step: email verification, password entry, plan selection, payment submission. The ratio of completions tells you your funnel health.

signup_step_completed_total{step="email_verified"} 4200
signup_step_completed_total{step="password_set"} 4150
signup_step_completed_total{step="plan_selected"} 4100
signup_step_completed_total{step="payment_processed"} 3980

If email_verified is 4200 but payment_processed is 3980, you're losing 55 customers (1.3%) at payment. That's data for your product team: the payment UX needs work.

For payment systems, track success and failure rates per payment provider (Stripe, PayPal, etc.), per currency, and per plan tier. When success rate for annual plans drops from 98% to 92%, your team knows to contact Stripe support or investigate fraud detection rules that got too strict.

payment_attempts_total{provider="stripe",status="success",tier="annual"} 1543
payment_attempts_total{provider="stripe",status="failure",tier="annual"} 23
payment_attempts_total{provider="stripe",status="declined",tier="annual"} 8

Set alerts on these business metrics. A 5% drop in daily active users is a data-driven early warning that something is wrong upstream—maybe it's a slow service, maybe it's a bug in billing, maybe it's a competitor feature. But you'll spot the correlation faster with business metrics feeding your alerting engine.

Common mistakes

• Monitoring only happy paths. Instrument errors, timeouts, and retries. If you only measure successful requests, you'll miss degradation.
• Setting alerts on averages. Use percentiles (p95, p99) for latency. An average can mask the fact that 5% of users experience 10-second timeouts.
• Forgetting about external dependencies. Your SaaS likely calls third-party APIs (payment processors, email services, analytics). Monitor their latency and error rates as if they were your own services.
• Over-alerting on metrics that don't matter. CPU at 70% is not an alert. CPU approaching limits on a growing trend is. Alert on business impact, not raw utilization.
• Siloing metrics by team. Operations monitors infrastructure, backend monitors services, product monitors conversions. Share a single Grafana instance where anyone can see the full picture.

Key takeaways

• Monitoring a SaaS application spans four layers: edge uptime and TLS expiry, service RED metrics per endpoint, data layer health (database cache, queue lag), and business outcomes (signups, payment success).
• Use Blackbox Exporter for geographic uptime probes and certificate expiry alerts; they catch infrastructure issues before customers do.
• Instrument every API endpoint with per-endpoint latency percentiles and error counts—raw aggregate metrics hide real problems.
• Monitor your data layer actively: database cache hit ratio, Redis memory, Kafka consumer lag. Slow services usually stem from the data layer.
• Business metrics (funnel completion, payment success rate) are as critical as technical metrics. They're early signals of revenue impact.
• Centralize all metrics in one Grafana instance shared across teams. Siloed dashboards lead to blind spots.