Your application is a black box until you add monitoring. When a user reports "the app is slow, " you need to know: which endpoint, how slow, for how long, for how many users, and why. Without observability, you are debugging with guesswork.
The Three Pillars
Metrics are numerical measurements over time: request latency, error rate, CPU usage, active users, queue depth. Metrics tell you what is happening at a high level. They are cheap to collect and fast to query.
Logs are discrete events: "User 1234 attempted login at 10:42:17, failed: invalid password." Logs tell you what happened in detail. They are expensive to store at scale but essential for debugging specific incidents.
Traces follow a single request across services: client to API gateway to auth service to database and back. Traces tell you where time is being spent. Critical when a request touches 3+ services and you need to find the bottleneck.
For most startups, start with metrics and logs. Add tracing when your architecture grows beyond 2-3 services.
What to Monitor First
In priority order:
Uptime and availability. Is your app reachable? Synthetic monitoring (Uptime Robot, Better Uptime, or Checkly) pings your endpoints every 30-60 seconds and alerts when they go down. This is the most basic and most important monitor. Set it up today, it takes 5 minutes and is often free.
Error rate. What percentage of requests return 5xx errors? Healthy baseline: under 0.1%. Alert threshold: above 1%. Track this per endpoint, a 10% error rate on your payment endpoint is critical even if your overall rate is 0.5%.
Response time. P50 (median), P95, and P99 latency for your API endpoints. P50 tells you the typical experience. P95 tells you what your unhappy users see. P99 catches outliers that might indicate a systemic issue. Alert on P95 crossing 2x your normal baseline.
Resource utilization. CPU, memory, disk, and database connections. These are leading indicators, resource exhaustion causes the errors and latency that users feel. Alert at 80% utilization to give yourself time to react.
Alerting Without Alert Fatigue
Most monitoring setups fail not because they miss issues but because they generate too many alerts. Engineers mute them, and then a real incident goes unnoticed.
Alert on symptoms, not causes. Alert on "error rate above 2%" not "CPU above 80%." High CPU might be fine during a traffic spike. High error rate always means something is wrong.
Two severity levels only. Page (wake someone up): site is down, error rate above 5%, data loss risk. Notify (Slack message, check next business day): elevated error rate, degraded performance, resource warning. Everything else goes into a dashboard.
Aggregate and deduplicate. Group related alerts. "Database connection pool exhausted" and "API timeout on /users" and "500 errors on /dashboard" are all the same incident, do not send three pages.
Tools Worth Paying For
Sentry ($26/month and up), error tracking with stack traces, breadcrumbs, and release tracking. The most impactful single tool for a startup. See exactly which line of code caused an error, on which browser, for which user. We use this on every project.
Vercel Analytics (included with Vercel hosting), web vitals, function execution metrics, and deployment tracking. If you host on Vercel, this is free and covers 80% of your web performance monitoring needs.
Datadog ($15/host/month and up), full observability platform with metrics, logs, traces, and dashboards. Powerful but expensive. Worth it when you have 5+ services and need correlated views across your stack. Overkill for most startups under Series A.
Grafana Cloud (free tier available), open source dashboarding with hosted metrics and logs. Best value for startups who want Datadog level visibility without Datadog level bills. Pair with Prometheus for metrics and Loki for logs.
PagerDuty or Opsgenie ($21/user/month), on call management and incident routing. Necessary once you have an on call rotation. Handles escalation, acknowledgment, and post incident tracking.
SLOs and Error Budgets
A Service Level Objective (SLO) is a target: "Our API will return successful responses 99.9% of the time." The error budget is the inverse: you are allowed 0.1% errors per month (about 43 minutes of downtime).
Why this matters: when your error budget is healthy, ship features aggressively. When it is burning, slow down and fix reliability. This gives your team an objective framework for the speed vs stability tradeoff instead of arguing about it every sprint.
Start simple: one SLO for availability (99.9%) and one for latency (P95 under 500ms). Measure monthly. Adjust thresholds based on your actual user expectations.
The Real Cost of Downtime
For a SaaS product making $50K/month in revenue: 99.9% uptime means $50 in lost revenue per month from downtime. Sounds tolerable. But downtime also means: customer support tickets, trust erosion, potential contract SLA violations, and emergency engineering time at 3x normal cost (overtime, context switching, missed other work).
The real cost of an hour of downtime is typically 5-10x the direct revenue impact. Monitoring pays for itself by reducing mean time to detect (MTTD) from hours to minutes and mean time to resolve (MTTR) from hours to under 30 minutes.
Our ongoing management practice includes full monitoring setup as standard, because software maintenance without monitoring is just hoping for the best. We integrate it into your CI/CD pipeline so monitoring evolves with your code.
Need monitoring set up properly? Let us build the observability layer your app needs.