API monitoring basics · alerting for API errors · latency monitoring API · uptime tracking API · observability · indie developers
API Monitoring Basics for Indie Developers: Latency, Errors, and Uptime Without the Enterprise Bloat
A practical guide to setting up API monitoring and alerting for small teams—tracking latency, error rates, and uptime without overcomplicating things with enterprise-grade tooling.
Published:
Stop Guessing, Start Measuring
If you ship APIs as part of your product, you already know the feeling: a user reports something is broken, and you have no idea whether it is a latency spike, a 5xx cascade, or a transient network hiccup. The fix is not a $500-per-host observability platform. It is a small set of signals, collected consistently, with alerts that actually mean something.
This guide covers the three signals every indie developer and small team should track—latency, error rates, and uptime—and how to wire them into alerts without drowning in configuration.
The Three Signals That Matter
1. Latency Monitoring API
Latency is the time between a request leaving your client and a response arriving back. For API consumers, this is the single most visible metric. A slow API feels broken even when it is technically available.
What to track:
- p50, p95, and p99 latency per endpoint. The mean is useless; it hides tail latency that hurts real users.
- Breakdown by endpoint. A single average across all routes masks the fact that one heavy query is dragging everything down.
- Upstream vs. internal time. If your API calls a database or another service, separate the time spent waiting on that dependency. A 200 ms response that is 180 ms database wait is a different problem than a 200 ms response that is 200 ms of your own code.
How to collect it without enterprise tooling:
- Add a middleware or decorator that records request start time, endpoint, status code, and duration. Emit this as a metric to any time-series store (Prometheus, InfluxDB, even a simple TimescaleDB table).
- If you already use New Relic, the Postman integration gives you instant observability into latency, request counts, and error rates alongside your existing telemetry, with a pre-built dashboard you can install in minutes [8].
- For a lightweight approach, log structured JSON with a timestamp and duration field to a log aggregator, then query it with a simple NRQL or SQL statement.
2. Alerting for API Errors
Error rates are straightforward to define but tricky to alert on sensibly. A 1% error rate on a high-traffic endpoint is worse than a 5% error rate on a low-traffic internal tool. Context matters.
What to track:
- 4xx vs. 5xx separation. Client errors (4xx) and server errors (5xx) require different responses. Alerting on them together produces noise.
- Error rate by endpoint and by status code class. Know which route is failing and whether it is a validation issue or an internal failure.
- Absolute error count in addition to rate. A 0.1% error rate on 10 requests is one error. A 0.1% error rate on 100,000 requests is a crisis. Set thresholds on both.
How to build alerts that do not wake you up at 3 AM for nothing:
- Use self-adjusting thresholds or anomaly detection where available. New Relic offers these capabilities out of the box, so you get notified when your APIs have poor performance without hardcoding static limits that drift out of relevance [8].
- Apply exclusionary filtering to avoid alerting on non-production environments. A flaky staging endpoint should not page your on-call engineer.
- Start with a warning threshold (e.g., error rate exceeds 2% for 5 minutes) and a critical threshold (e.g., error rate exceeds 5% for 3 minutes). Escalate, do not immediately page.
- If you manage alerts programmatically, the REST API lets you list, create, update, and delete alert conditions across policies, which is useful when you need consistency across multiple clusters or services [7]. You can also disable and enable conditions on the fly during deployments or maintenance windows [10].
3. Uptime Tracking API
Uptime is the simplest signal and the one most people get wrong. Ping-based monitoring from a single location tells you whether your API responds to a health check, not whether it is usable.
What to track:
- Synthetic checks from multiple locations. A user in Frankfurt should not be told your API is up when the only probe hitting it is in Virginia.
- Mean Time to Detection (MTTD). How long after an outage begins do you know about it? This is more important than the uptime percentage itself.
- Mean Time to Resolution (MTTR). Track this alongside MTTD to measure real reliability.
How to set it up practically:
- Use a dedicated uptime service (UptimeRobot, Checkly, or a simple cron job hitting a lightweight health endpoint) with checks from at least two geographic regions.
- Make your health endpoint return meaningful status. A 200 OK from
/healththat does not check the database or downstream dependencies is a false sense of security. - Log every check result with timestamp, location, status code, and response time. Store this data and compute uptime as a rolling window (15-minute, hourly, daily).
- New Relic’s infrastructure monitoring REST API allows you to manage alerting conditions programmatically, which is useful when you need to define the same conditions across many hosts or apply exclusion filters that the UI does not support [9].
Putting It Together: A Minimal Monitoring Stack
You do not need a full APM suite to monitor your APIs effectively. Here is a stack that works for a small team:
- Instrument your code. Add latency and error tracking at the API layer. Emit structured metrics.
- Choose a storage backend. Prometheus for self-hosted, or a managed service like New Relic if you want to move faster [6].
- Build or install dashboards. One view for latency percentiles by endpoint, one for error rates by status class, one for uptime from synthetic checks.
- Configure alerts. Start with warning and critical thresholds on error rate and p95 latency. Add uptime alerts only after you have MTTD data.
- Review and tune monthly. Alerts that fire without action are worse than no alerts. Kill noisy conditions.
FAQ
Do I really need p99 latency, or is p95 enough? p95 catches the worst 5% of requests. p99 catches the worst 1%. If your API serves real-time or interactive workloads, p99 matters. If it is batch or async, p95 is usually sufficient.
Can I skip synthetic uptime checks and rely on logs? No. Logs tell you what happened after the fact. Synthetic checks tell you whether the API is reachable before a user complains. They serve different purposes.
How do I alert on errors without alert fatigue? Separate 4xx from 5xx. Use anomaly detection instead of static thresholds where possible. Add a cooldown period so a single spike does not trigger repeated pages.
Is the REST API approach worth it for a small team? If you manage multiple environments or need to automate alert setup across services, yes. The REST API gives you consistency and the ability to script condition changes [7]. If you have one service and five alerts, the UI is fine.