5 exercises — traceId and distributed tracing, connection pool exhaustion, degraded health checks, circuit breakers, and rate limiting. Read log evidence and communicate findings clearly.
0 / 10 completed
1 / 10
A log entry reads: {"timestamp":"2026-04-07T03:14:22.441Z","level":"ERROR","service":"payment-api","traceId":"9f2c1d8e","userId":"usr_8821","msg":"charge failed","error":"card_declined","duration_ms":312}
A colleague asks: "Which field should I use to find all other log entries from the same request across multiple services?" What is your answer?
traceId (also called correlation ID or request ID) is the key field for distributed tracing.
What traceId means: When a single user action (e.g., a payment) touches multiple services (payment-api → fraud-service → bank-gateway → notification-service), a single traceId is injected at the first service and passed to every downstream service. This allows you to reconstruct the complete request path across all services.
Common names for this field: • traceId, trace_id • requestId, request_id • correlationId, X-Correlation-ID • spanId (sub-request within a trace in OpenTelemetry)
In Kibana/Splunk/Grafana Loki: traceId: "9f2c1d8e" → shows all log lines across all services for this request
Other fields explained: • service — identifies which service emitted the log • userId — identifies the user (may span many requests) • duration_ms — how long the operation took • error — machine-readable error code (vs msg which is human-readable)
2 / 10
You see these two log entries from the same service within 2 seconds: {"level":"WARN","msg":"database connection pool exhausted, waiting for connection","pool_size":10,"waiting":8} {"level":"ERROR","msg":"database query timeout after 30000ms","query":"SELECT * FROM orders WHERE...","timeout_ms":30000}
What is the correct interpretation of what these two log lines are telling you together?
These two log lines together tell a causal story — read them in sequence:
Line 1 (WARN):pool exhausted, waiting: 8 → All 10 database connections are occupied. 8 requests are queued waiting for a free connection. → This is a warning, not yet an error — the system is degraded but still functioning.
Line 2 (ERROR):query timeout after 30000ms → A request waited so long for a connection (or the query itself ran long) that it hit the 30-second timeout. → This is now an error — requests are failing.
Possible root causes to investigate: 1. Slow queries — queries holding connections too long, blocking the pool 2. Connection leak — connections opened but never returned to the pool 3. Traffic spike — more concurrent requests than the pool supports 4. Pool size too small for current load
Key log reading vocabulary: • pool_exhausted / waiting — resource saturation signal • timeout after Nms — request did not complete within the allowed time • connection leak — connections not returned to pool • pool_size — maximum concurrent database connections configured
3 / 10
A log entry shows: {"level":"INFO","msg":"health check","status":"ok","checks":{"db":"ok","redis":"ok","queue":"degraded"},"duration_ms":45}
What action, if any, does this log entry require?
Log levels are not the whole picture — always read the content too.
This is an important trap: the level is INFO, which may seem benign, but the content shows a degraded dependency.
Understanding status: degraded in health checks: • ok — fully healthy • degraded — functioning but with reduced capacity or elevated error rate • failure / error — not functioning
A "degraded" queue might mean: • Consumer lag is increasing (messages not being processed fast enough) • The queue is approaching its size limit • Some queue workers are down • Connection retries are occurring silently
Why this was logged at INFO, not WARN or ERROR: The health check itself completed successfully (it checked and returned a result). The health check service often logs at INFO regardless of component status, relying on downstream alerting to trigger on degraded values.
Standard health check log vocabulary: • status: ok — all components healthy • status: degraded — service is up but one or more components are impaired • status: unavailable / down — service is not serving traffic • checks: { component: "degraded" } — per-dependency health detail
4 / 10
During an incident, you find this log line: {"level":"ERROR","msg":"upstream service unavailable","upstream":"inventory-service","attempts":3,"last_error":"connection refused (ECONNREFUSED)","circuit_breaker":"open"}
What does "circuit_breaker: open" mean in this context?
A circuit breaker is a resiliency pattern that stops calling a failing upstream service to prevent the failure from spreading.
Circuit breaker states: • Closed (normal) — requests pass through; failures are counted • Open — threshold of failures exceeded; ALL requests to this upstream are immediately rejected (no attempt made) for a timeout period • Half-open — timeout expired; allows a few test requests through to see if the upstream has recovered
Why "open" is actually a protective measure, not a problem: Without a circuit breaker: 1. inventory-service returns ECONNREFUSED 2. Every request tries to call it and waits for a timeout 3. Thread pool fills up waiting for timeouts 4. Your service becomes slow or unresponsive (cascade failure)
With an open circuit breaker: 1. Requests that need inventory-service fail fast with a clear error 2. Other functionality continues working 3. Your service logs clearly what is unavailable
ECONNREFUSED meaning: The operating system returned "Connection Refused" — the target host exists but nothing is listening on that port. This usually means the upstream service process has crashed or is restarting.
Key vocabulary: • upstream — a service that this service calls • attempts: 3 — tried 3 times before failing • circuit_breaker: open — requests blocked until upstream recovers • ECONNREFUSED — OS-level: port exists but nothing listening
5 / 10
You are investigating a spike in errors. You find this log entry: {"level":"WARN","msg":"rate limit applied","client_ip":"203.0.113.42","endpoint":"/api/search","requests_last_minute":847,"limit":100,"action":"throttled","retry_after_ms":24000}
Write a one-sentence Slack incident update based only on the information in this log line. Which of the following is the best update?
A good incident update translates technical log data into a clear, factual, actionable statement.
Why option B is best: 1. States the specific fact: one client IP, specific endpoint, specific rate (847 vs 100 limit) 2. Describes the system response: throttled, retry in 24s (the system is working as designed) 3. Acknowledges uncertainty: "Investigating whether..." — correctly notes this is being analyzed, not yet resolved 4. Lists possible root causes: three plausible explanations without guessing
What makes the other options poor: • A — vague: "something is wrong" provides no actionable information • C — misinterpretation: the rate limiter is working correctly; calling it "broken" is wrong • D — wrong action: no evidence that a restart would help
Key log fields to extract for incident updates: • client_ip → WHO is causing the issue • endpoint → WHAT is being affected • requests_last_minute: 847 vs limit: 100 → HOW SEVERE • action: throttled → SYSTEM RESPONSE (is it being handled?) • retry_after_ms: 24000 → RECOVERY TIME
Incident update vocabulary: "A client is exceeding rate limits on [endpoint] — throttling has been applied." "Investigating whether this is [X], [Y], or [Z]." "The system is handling this via [mechanism]; no service disruption at this time."
6 / 10
John from the DevOps team sends you this Slack message: 'I'm seeing a lot of `ERROR` logs coming from our `user-profile-service`. The last one says {'level':'ERROR','msg':'authentication failure','userId':'usr_1234','error':'invalid_token'}. What should I investigate first?'
What is the most appropriate next step based on this log entry?
The log clearly indicates an 'authentication failure' which suggests a problem with user access. Scaling resources is premature without understanding *why* authentication is failing. Investigating the token validity and session details will pinpoint whether the issue is related to a compromised token or a misconfigured session – this is the most targeted initial action. Notifying security immediately might be warranted, but validating the authentication attempt comes first.
7 / 10
You're reviewing a PR that adds logging to a new feature in the `order-processing` service. The commit message includes this log entry:
{'level':'INFO','msg':'new order created','orderId':'ord_5678','userId':'usr_9012'}.
Your reviewer asks: 'Can you explain what this log entry tells us about the success of the order creation?' What is your response?
This `INFO` level log explicitly states 'new order created' and associates it with an `orderId` and `userId`. This confirms that the order was successfully created. The other options misinterpret the log entry's purpose – INFO logs typically denote successful events, not errors or ambiguous situations. The lack of error codes is expected for a successful creation.
8 / 10
During a system outage, you're analyzing logs and find this entry:
{'level':'ERROR','msg':'connection refused (ECONNREFUSED)','service':'shipping-api','port':8080,'attempts':5}.
What does the `ECONNREFUSED` error most likely signify?
'ECONNREFUSED' (Error Connection Refused) is a standard network error. It means that the client attempted to connect to the specified host and port but no process was listening on that port. This strongly suggests that the shipping API service isn't running or is unavailable at port 8080 – typically, it would be unreachable due to a network problem or being intentionally shut down. The other options represent alternative interpretations of connection errors.
9 / 10
You're investigating performance degradation in the `recommendation-engine`. You discover this log entry:
{'level':'WARN','msg':'high CPU utilization','service':'recommendation-engine','cpu_usage':85,'duration_ms':120}.
What immediate action should you consider based solely on this log?
The log clearly indicates high CPU utilization. This suggests that the *algorithm* or the *data processing* within the recommendation engine is consuming excessive resources. Restarting might provide temporary relief but doesn't address the root cause. Scaling up before identifying algorithmic issues would be wasteful. Monitoring network latency could be a secondary investigation, but the primary focus should be on optimizing the engine's logic.
10 / 10
A colleague sends you this Slack message: 'We're seeing lots of `WARN` logs from our `billing-service`. One says {'level':'WARN','msg':'invalid billing amount','userId':'usr_3456'}. What do we need to do?'
What is the best single-sentence Slack update you should provide?
The Slack update needs to concisely communicate the problem and the initial direction of investigation. 'We're investigating a potential issue with user billing amounts, focusing on `usr_3456`' provides this information effectively. It highlights the specific error and the user involved, indicating where further action should be taken. The other options are either too vague or inappropriately reactive.
What will I practise in "Reading JSON Logs — Log Reading Exercises"?
Practice reading structured JSON logs: traceId for distributed tracing, connection pool exhaustion, health check status fields, circuit breakers, and rate limit events. 5 exercises.
How many exercises are in this module?
This module has 10 multiple-choice exercises, each with instant feedback and a full explanation of the correct answer.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do I need to create an account to do these exercises?
No account is required. Just click an option to answer — your score for this session is tracked automatically in the progress bar above.
What happens if I choose the wrong answer?
You'll immediately see which answer was correct, plus a full explanation covering the vocabulary and reasoning behind it — mistakes are where most of the learning happens.
Can I retry the exercises if I want a higher score?
Yes — use the "Try again" button on the results screen to reset and go through all the questions again.
Is my progress saved if I close the page?
No. Progress is tracked only for your current visit; reloading or leaving the page resets the counter. This keeps the exercise simple and account-free.
Where can I find more Log Reading exercises?
Browse the full Log Reading hub for related drills, or check the "Next up" link below to continue with a connected topic.
How is this different from reading an article on the same topic?
Articles explain vocabulary and concepts in prose; this exercise tests and reinforces that vocabulary through active recall with immediate feedback — the two work best together.
Who writes these exercises?
Every exercise is written by the CoderSlingo team, drawing on real workplace English used in IT roles, then reviewed for accuracy and clarity.