Application monitoring vs server monitoring
Server monitoring watches CPU, disk, and host health. Application monitoring asks whether the customer path works — HTTP status, TCP ports, heartbeats from jobs. Hosts can look fine while login returns 500.
Healthy teams run both. Start with the paths that touch revenue: checkout, login, payment webhooks, and critical APIs.
Metrics and checks that matter
Uptime percentage alone hides pain. Track latency budgets, error rates, SSL expiry, and dependency health. Synthetic checks from outside your VPC catch DNS and edge failures internal agents miss.
- HTTP/HTTPS probes on key URLs with content assertions when needed
- TCP checks for databases or mail listeners you own
- Heartbeat / cron “I am alive” tokens for background work
- Status page for humans who should not need your Slack invite
Alerts without fatigue
Alert on state changes someone will fix at 3 a.m., not on every blip. Use severity, routing, quiet hours, and flapping suppression. Echo focuses on clear up/down messaging with email, Slack, and webhooks; custom stacks can add on-call graphs when you outgrow product defaults.
Cost expectations
Cost scales with probe count, regions, retention, and seats. Start narrow on revenue paths, then widen. Custom monitoring for private networks costs engineering time; productized Echo covers the common SaaS/uptime case faster.
Also price downtime: one checkout outage often eclipses a year of probing.