REST API Monitoring and Logging
An API that works today can fail tomorrow. A slow database, a bad release, or a traffic spike can break the service while no one notices. Monitoring and logging give teams eyes and memory. They show what happens now and what happened before.
The Car Dashboard Picture
A car dashboard shows speed, fuel, and engine warnings. A trip log records the route and stops. The dashboard helps the driver act in the moment, and the log explains a problem after it occurs. Metrics act as the dashboard of an API, and logs act as the trip log.
Three Pillars of Observability
| Pillar | Question It Answers | Example |
|---|---|---|
| Logs | What happened? | Request 8841 returned 500 at 10:42 |
| Metrics | How is the system behaving? | Average latency is 180 ms |
| Traces | Where did the time go? | 70 percent of the request waited on the database |
What to Log
Each request should leave one structured log line in JSON. Structured logs let tools search and count by field.
{
"time": "2026-11-01T10:42:07Z",
"requestId": "req-8841",
"method": "GET",
"path": "/orders/7",
"status": 500,
"durationMs": 912,
"userId": "user-4821",
"error": "database timeout"
}
What to Keep Out of Logs
- Passwords, tokens, and API keys.
- Full card numbers and government ids.
- Private message text and health data.
Mask or drop sensitive fields before writing the log. Set a retention period, and delete old logs on schedule to respect privacy laws.
Correlation IDs
One user action may touch five services. A correlation ID ties every log line from that action together. The first service creates the ID, usually in an X-Request-ID header, and each service passes it along.
Gateway [req-8841] received GET /orders/7 Orders [req-8841] loading order Users [req-8841] loading profile Orders [req-8841] ERROR database timeout
Searching for req-8841 shows the whole story in order.
The Four Golden Signals
| Signal | Meaning |
|---|---|
| Latency | How long requests take, tracked as p50, p95, and p99 |
| Traffic | How many requests arrive per second |
| Errors | The share of requests that fail, especially 5xx statuses |
| Saturation | How full CPU, memory, and connections are |
Averages hide pain. A p99 latency of 4 seconds means one in a hundred users waits four seconds, even when the average looks fine.
Alerts
Alerts should point to problems that need action. An alert for every small blip trains people to ignore messages. Good alert rules focus on user impact.
Error rate above 5% for 5 minutes ──→ page the on-call engineer p95 latency above 2 seconds for 10 minutes ──→ send a team message Disk usage above 80% ──→ create a ticket
Health Checks
A health endpoint such as GET /health returns 200 when the service runs well. Load balancers poll it and remove unhealthy servers from rotation. A deeper readiness check confirms that the database and other dependencies respond.
Service Level Objectives
An SLO states a target in numbers, such as "99.9 percent of requests succeed each month". The gap between 100 percent and the target forms an error budget. Teams spend the budget on releases and experiments, and slow down when it runs low.
Common Mistakes
Logging Everything at Debug Level
Huge log volume raises costs and buries the useful lines. Use debug logs only while investigating.
No Baseline
Without normal numbers on record, nobody can tell whether 300 ms is slow. Collect metrics from the first day.
Unread Dashboards
A dashboard nobody checks protects nothing. Tie each chart to an alert or a regular review.