Intermediate Reading Practice #incident-response #status-pages #sre

📡 Reading Service Status Updates

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 / 5 completed

1 / 5

Read the service status entry below and answer the question.

✓ Resolved Increased 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?

2 / 5

Read the incident impact description and choose the best plain-English summary for a non-technical stakeholder.

⚠ Incident Degraded 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?

3 / 5

Read the post-incident summary and identify the root cause.

✓ Resolved Database 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?

4 / 5

Read this planned maintenance notice and answer the question.

📅 Planned Maintenance Scheduled 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?

5 / 5

Read the post-resolution update and choose the correct description of what will happen next.

✓ Resolved Cache 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 #1: Review Redis cluster configuration for multi-AZ leader election timeout settings
Action item #2: Add automated alerting for Redis leader election events
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?