5 exercises — read real-style service status pages, incident reports, and maintenance notices. Extract timing, impact descriptions, root causes, and next steps.
What to look for in a status update
Duration: Incident opened / resolved times → subtract for total TTR
Impact: Which services? Which users? What percentage? What error?
Root cause: The specific technical reason — not the symptom
Next steps: Action items to prevent recurrence (different from resolution)
Behaviour changes: Any permanent changes after a maintenance window
0 / 16 completed
1 / 16
Read the service status entry below and answer the question.
✓ ResolvedIncreased API Error Rates — Payments Service (eu-west-1)
Summary: Customers in the EU (Ireland) region experienced elevated HTTP 500 error rates when calling the Payments API. Approximately 12% of requests were affected.
Incident opened: 2026-03-12, 14:23 UTC
Incident resolved: 2026-03-12, 15:47 UTC
Monitoring ended: 2026-03-12, 16:15 UTC
How long did the Payments API incident last, from detection to resolution?
About 84 minutes — 1 hour and 24 minutes. To calculate incident duration, subtract the incident open time from the resolution time:
Why not 112 minutes? The "monitoring ended" time (16:15) is when the team stopped watching for recurrence — not when the incident was resolved. Always use the "Resolved" or "Resolution time" field for incident duration.
Saying it aloud: "The Payments API outage lasted one hour and twenty-four minutes." or "The incident ran for approximately eighty-four minutes."
In a post-mortem: "Total time to resolution (TTR): 84 minutes. Time spent investigating: ~45 min. Time to apply fix and confirm: ~39 min."
2 / 16
Read the incident impact description and choose the best plain-English summary for a non-technical stakeholder.
⚠ IncidentDegraded Performance — User Authentication Service
Impact: Approximately 18% of login requests are timing out after 30 seconds. Users who had already authenticated are not affected. Failed requests are returning HTTP 504 (Gateway Timeout). The authentication service is processing requests, but response times have increased from a baseline of ~120ms to 8,000ms+ for affected requests.
Which summary best describes this impact for a product manager or CEO?
"About 1 in 5 users trying to log in are experiencing a 30-second wait before seeing an error."
Why this is the best translation: ① "About 1 in 5 users" — converts 18% to a human-readable ratio; easier to visualise than a percentage ② "trying to log in" — specifies who is affected (only users attempting new logins) ③ "30-second wait before seeing an error" — describes the user experience accurately ④ "Users already logged in are not affected" — addresses the immediate concern: is the whole product broken?
Why the others are wrong: • "Completely down" — incorrect and alarmist; 82% of login attempts succeed • "8% of HTTP requests" — the wrong percentage and wrong scope; this was about login requests • "8,000 milliseconds system-wide" — technical units without context; a non-technical stakeholder doesn't know 8,000ms is bad
Rule: When writing incident impact for non-technical audiences, convert metrics to user experience ("1 in X users experience Y"), specify who is affected, and avoid raw technical units without context.
3 / 16
Read the post-incident summary and identify the root cause.
✓ ResolvedDatabase Connection Pool Exhaustion — Reporting Service
Timeline:
09:00 — Scheduled weekly analytics report job started
09:03 — Reporting service response times began increasing
09:09 — Database connection pool reached maximum (100/100 connections used)
09:12 — New API requests began returning HTTP 503 (Service Unavailable)
09:23 — On-call engineer identified connection pool exhaustion in metrics
09:31 — Report job manually terminated; connection pool recovered
09:35 — All services returned to normal
Root cause: The weekly analytics report job was not using database connection pooling. Each query opened a new connection without releasing it, exhausting the shared pool and blocking all other database consumers.
What was the root cause of the 503 errors?
The report job opened connections without releasing them, exhausting the shared pool.
Why this is the root cause (not a contributing factor): The root cause is the specific technical reason the incident happened — not the timing, not the response, not the infrastructure limit being reached. The report job's missing connection pool configuration was the direct cause. Without it, the incident doesn't happen.
Why the other options are wrong: • "Database crashed" — the database didn't crash; the connection pool was exhausted. These are different. The database was running; it just couldn't accept new connections • "Engineer failed to respond" — response time affects duration, not root cause; the incident would have happened regardless • "Insufficient server memory" — the 100-connection limit is a normal ceiling; the problem was the job's failure to release connections, not the limit itself
Blameless RCA language: "Root cause: The report job was not configured to use the shared connection pool. Each query opened a new permanent connection. This is a misconfiguration in the job's database client settings, not a capacity issue."
Tip: Root cause analysis should identify the process or configuration failure, not just the symptom (connection pool full) or the timeline (it broke at 09:09).
4 / 16
Read this planned maintenance notice and answer the question.
📅 Planned MaintenanceScheduled Downtime — All API Services
Window: Saturday, 2026-03-21, 02:00–05:00 UTC
Expected duration: Up to 3 hours. Services may return before the window ends.
Affected services: REST API v2, GraphQL API, Webhook delivery, API authentication endpoint.
Not affected: Static assets, documentation site, status page.
Action required: Customers who process webhooks automatically should pause webhook consumers during this window. Webhooks that fail during downtime will be retried automatically up to 3 times over the following 24 hours.
What's happening: TLS certificate infrastructure upgrade. After the window, all APIs will require TLS 1.3 minimum. TLS 1.2 connections will no longer be accepted.
A developer reads this notice and asks: "Will my integration break after the maintenance?" What is the critical information they need to check?
They need to verify their HTTP client and SDK support TLS 1.3.
Why: The most impactful change in this notice is not the downtime itself — it's the post-maintenance behaviour change: "TLS 1.2 connections will no longer be accepted."
This means: ① If the developer's SDK or HTTP client only supports TLS 1.2 (common in older Java, Python 2, and .NET Framework environments), the API calls will fail permanently after the maintenance window — not just during it ② The downtime lasts 3 hours and is temporary; the TLS change is permanent and breaking ③ This is a migration action item disguised inside a maintenance notice
What to look for in maintenance notices: • Behaviour changes after the window — these are permanent and require action • Deprecations — features being removed (here: TLS 1.2 support) • Action required section — always read this first • Retry / recovery behaviour — webhooks retried automatically; this is relevant but not the critical question
Reading tip: Not affected: static assets and docs. But not-affected sections help confirm scope, not the integration risk.
5 / 16
Read the post-resolution update and choose the correct description of what will happen next.
✓ ResolvedCache Layer Failure — Search Service
Resolution: The Redis cache cluster experienced a leader election failure following a network partition between availability zones. The cluster was non-functional for 47 minutes. During this period, all search queries fell back to the primary database, causing 8×–12× increased query load and elevated latency (p99: 4.2 seconds vs. baseline 340ms).
Status: Redis cluster has been restored and all search queries are served from cache as expected. Latency has returned to baseline.
Next steps:
Post-mortem scheduled: 2026-03-14, 11:00 UTC (blameless)
Action item #3: Load test database fallback path to validate it can handle 10× load without latency SLA breach
Based on the post-incident next steps, what is the team prioritising to prevent recurrence?
Three distinct action items: Redis configuration, alerting, and fallback validation.
Reading post-incident next steps accurately requires identifying each individual action item and understanding its purpose:
① Action item #1 — Redis multi-AZ configuration: Fix the root cause — the leader election timeout settings that failed during the network partition. This is the primary prevention action. ② Action item #2 — Alerting: Add visibility so the team detects leader election events before they cause an outage. Detection speed reduces incident duration. ③ Action item #3 — Load test fallback: The fallback path (database) worked — it absorbed the traffic. But the spike (~10× load) was unplanned. The team wants to confirm the database can handle it safely without breaching the latency SLA.
Why option B is wrong: The fallback to the primary database was the correct resilience behaviour during the cache failure. The team wants to validate it, not remove it. Disabling it would make a future cache failure catastrophic.
Key vocabulary in incident next steps: • "blameless post-mortem" — a retrospective focused on process/system failures, not individual blame • "action item" — a specific, assigned task with an owner • "validate" — test under controlled conditions to confirm the expected behaviour • "leader election" — a distributed systems protocol for selecting which node is the primary/leader
6 / 16
Sarah, a SRE, received this Slack message from the on-call engineer:
`@john.doe: Urgent! Payments API is spiking with 500 errors. Looks like a potential issue with transaction processing. Can you investigate?`
What's the most appropriate next step for Sarah based on this initial alert?
The Slack message indicates an urgent problem. Starting a full investigation is the most appropriate first step – gathering details and understanding the scope of the issue before taking drastic action. Deploying a new version or ignoring the alert could be premature and potentially disruptive. Contacting the payments team is also valuable, but should follow initial investigation.
7 / 16
Review this API response from the User Authentication Service during a peak load:
```json
{
"status": "error",
"code": 504,
"message": "Gateway Timeout"
}
```
What does this response *primarily* indicate about the system's current state?
A 504 Gateway Timeout error signifies that the server contacted by the User Authentication Service didn't respond within the allotted time. This strongly suggests overload and inability to handle requests efficiently. While network issues *could* cause a timeout, the message explicitly states 'Gateway Timeout', pointing towards resource constraints. The other options are less likely given this specific response code.
8 / 16
Mark, a developer, is writing a PR description for an incident involving increased latency in the Search Service. He writes:
`Fixed: Resolved performance degradation caused by inefficient database queries.`
Which of the following best improves Mark's description to be more informative and useful?
While Mark's initial description is a starting point, it lacks crucial context. Detailing *which* queries were problematic helps with future troubleshooting and understanding the root cause. Including the impact (slower search times) clarifies the user experience affected by the issue – this is vital for stakeholders. Using jargon is detrimental to clear communication.
9 / 16
During a standup meeting, Alex reports:
`Yesterday, we noticed an increased load on the Reporting Service. The database connection pool was maxed out, leading to 503 errors and delayed report generation.`
Which of the following is the *most* important takeaway from this update for the team?
Alex's update identifies the root cause: the lack of connection pooling. This is the critical information for the team to address – understanding *why* the problem occurred and what needs to be fixed. The other options are distractions or reactive measures rather than addressing the underlying issue.
10 / 16
David, a developer, received this email from the on-call SRE:
'The Reporting Service is experiencing high latency. Initial investigations suggest increased load impacting database query execution times. We're monitoring closely.' Which of the following best describes the SRE's primary concern?
The email focuses on 'high latency' and 'increased load impacting database query execution times,' indicating a performance issue rather than a system outage or security breach. The SRE is prioritizing investigating the root cause of the slow response times. Option A is incorrect because it describes a complete failure; options C and D are irrelevant to the described situation.
11 / 16
You're reviewing a Slack message from a team member regarding an incident:
`@jane.doe: We've identified a spike in errors on the Payment Service (us-east-1). The logs show excessive retry attempts after API calls to the external payment gateway. We suspect a timeout issue.` What is the *most* likely underlying problem being described?
The message highlights 'excessive retry attempts after API calls' and 'timeout issue,' strongly suggesting problems with the external payment gateway. This is a common scenario where the Payment Service is attempting to communicate with a third-party service that's momentarily unavailable or slow. Options A, B, and C are less likely given the specific wording of the message.
12 / 16
You receive this API response:
```json
{
"status": "error",
"code": 502,
"message": "Bad Gateway"
}
```
What does this response *primarily* indicate about the Search Service?
A 502 Bad Gateway error signifies that the Search Service was unable to receive a valid response from another server (likely a upstream service). This often points to network connectivity issues or temporary unavailability of a dependency. Options B, C and D would indicate different types of errors.
13 / 16
Emily, a DevOps engineer, receives this Slack message from the on-call team:
`@peter.jones: High CPU utilization detected on the User Authentication Service. Initial diagnostics point to a potential memory leak in the token validation module. Can you investigate?`
Which of the following best describes the *most immediate* concern Emily should address based on this message?
The message highlights a *memory leak* in the token validation module. This is a critical concern because uncontrolled memory growth can lead to instability and eventual system failure. Scaling resources might mask the problem temporarily but doesn't address the root cause – the leak itself. Focusing on configuration issues related to resource consumption offers the most direct path toward mitigation.
14 / 16
Mark, a developer, is drafting a PR description for an incident affecting the Search Service. He writes:
`Fixed: Optimized database query execution to reduce latency.`
Which of the following best describes the *most appropriate* level of detail Mark should include in this description?
The primary goal of a PR description is to communicate the change's impact to reviewers. While technical details are important, focusing on the *benefit* – reduced latency for users – provides context and demonstrates value. Overly detailed explanations can be confusing and don't clearly convey what was achieved. Acknowledging future work or simply stating resolution isn't informative.
15 / 16
Sarah, an SRE, receives this Slack message from the on-call engineer:
`@david.lee: We're seeing a spike in HTTP 502 Bad Gateway errors coming from the Reporting Service. The logs show connections to the database are timing out. What's going on?`
What is the *most likely* underlying cause of these 502 errors, based on the provided information?
HTTP 502 Bad Gateway errors typically indicate a problem with communication between servers. The Slack message specifically mentions 'connections timing out,' pointing to a network-related issue – likely a delay or failure in the connection between the Reporting Service and the database server. While other options are possible, they aren't directly supported by the log information.
16 / 16
Read the following Slack message from an on-call engineer and select the most appropriate action to take.
`@alex.smith: Urgent! The Payment Service in us-west-2 is returning a high volume of 503 errors. Users are reporting intermittent failures when attempting to process transactions. Initial checks show increased CPU usage.`
What should you do first?
The message indicates an active incident with user impact. Escalating to Tier 2 support is the correct initial step for immediate infrastructure investigation – this avoids unnecessary developer intervention and speeds up resolution. Options A and C are premature; a rollback could worsen the situation, and detailed reporting should follow investigation. Option B suggests immediate action without understanding the problem.
What will I practise in "📡 Reading Service Status Updates"?
This module focuses on Numbers, Data & Metrics — real workplace phrasing you'll use on the job. It contains 16 scenario-based multiple-choice questions with instant feedback.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account or sign-up required.
How many questions does this exercise have?
This module includes 16 questions. Each one gives an immediate right/wrong result plus a full explanation of the correct phrasing.
What happens if I answer a question incorrectly?
You'll see the correct answer highlighted straight away, along with a plain-English explanation of why it's right and why the other options don't fit — mistakes are part of the learning here.
Can I retry the exercise if I want a better score?
Yes — use the 'Try again' button on the results screen to reset your score and go through the questions again. There's no limit on attempts.
Who is this Numbers, Data & Metrics exercise for?
It's aimed at IT professionals with working English who want to sound more natural and precise around numbers, data & metrics — useful whether you're preparing for real conversations at work or just building confidence with the vocabulary.
Do I need an account to track my progress?
No account is needed. Your progress through the exercise is tracked locally in your browser for the current session, and you can replay the module at any time.
How is this different from reading a blog article?
This exercise is an interactive drill that tests and reinforces specific phrasing through multiple-choice questions with instant feedback, while blog articles explain concepts and vocabulary in prose. The two work well together.
Where can I find more Numbers, Data & Metrics exercises?
See the Numbers, Data & Metrics hub for more modules like this one, or browse the full Exercises page for other IT-English topics.
Can I complete this exercise on my phone?
Yes — every exercise on CoderSlingo is fully responsive and works on phones and tablets, so you can practise anywhere.