Timeout Status Records
An easy SQL interview practice problem on DataDriven. Write the query and run it against a real database, with instant feedback.
- Domain
- SQL
- Difficulty
- easy
- Seniority
- L3
- Asked in
- Yelp
Problem
During an incident investigation, you suspect some service health records have a timeout status. Find all rows with that status value and return all available fields for each matching row.
Unknown status in the health records.
Tables
svc_health
Columns: check_id INTEGER, svc_name TEXT, status TEXT, latency REAL, uptime REAL, checked TEXT, region TEXT
| check_id | svc_name | status | latency | uptime | checked | region |
|---|---|---|---|---|---|---|
| 137 | payment-api | degraded | 3.6 | 97.03 | 2026-02-02 01:05:00 | us-west-2 |
| 174 | user-svc | unhealthy | 6.7 | 94.06 | 2026-03-03 02:10:00 | eu-west-1 |
| 211 | search-api | timeout | 9.8 | 91.09 | 2026-04-04 03:15:00 | ap-south-1 |
| 248 | gateway | Healthy | 12.9 | 98.12 | 2026-05-05 04:20:00 | eu-central-1 |
| 285 | notif-svc | DEGRADED | 16 | 95.15 | 2026-06-06 05:25:00 | us-east-1 |
| 322 | ml-serving | healthy | 19.1 | 92.18 | 2026-07-07 06:30:00 | us-west-2 |
| 359 | cache-svc | degraded | NULL | 99.21 | 2026-08-08 07:35:00 | eu-west-1 |
| 396 | queue-worker | unhealthy | 25.3 | 96.24 | 2026-09-09 08:40:00 | ap-south-1 |
| 433 | cron-svc | timeout | 28.4 | 93.27 | 2026-01-10 09:45:00 | eu-central-1 |
| 470 | auth-svc | Healthy | 31.5 | 90.3 | 2026-02-11 10:50:00 | us-east-1 |
Expected output
| check_id | svc_name | status | latency | uptime | checked | region |
|---|---|---|---|---|---|---|
| 211 | search-api | timeout | 9.8 | 91.09 | 2026-04-04 03:15:00 | ap-south-1 |
| 433 | cron-svc | timeout | 28.4 | 93.27 | 2026-01-10 09:45:00 | eu-central-1 |
| 655 | notif-svc | timeout | 47 | 95.45 | 2026-07-16 15:15:00 | us-east-1 |
| 877 | payment-api | timeout | NULL | 97.63 | 2026-04-22 21:45:00 | us-west-2 |
| 1099 | cache-svc | timeout | 84.2 | 99.81 | 2026-01-28 03:15:00 | eu-west-1 |
Worked solution and explanation
What this is really asking
This is a single exact-value filter dressed up as an incident hunt. svc_health holds 200 health checks, and 31 of them carry the status 'timeout'. Everything else is 'healthy', 'degraded', 'unhealthy' or one of their capitalized cousins. Anyone can type SELECT *. What separates candidates is pinning the predicate to the exact value instead of returning the table or reaching for a fuzzy match. Forget the filter and the investigator gets all 200 checks, with the 31 failing probes buried among the healthy ones.
Step 1: Read the value off the sample rows
The sample rows show 'timeout' in lowercase next to 'Healthy' and 'DEGRADED' drifting in case. That drift is a reason to ask, not to normalize blindly. Timeout is always logged in lowercase here, so the literal you filter on is exactly 'timeout'.
Step 2: Filter on the literal
WHERE status = 'timeout' keeps exactly the 31 failing checks. An equality on a four-value column says precisely what the question asks and nothing more.
Step 3: Return every column untouched
The question wants every field, so SELECT * matches the ask. The preview shows all seven columns of svc_health, including the empty latency on check 877, so nothing is dropped, renamed or defaulted.
The solution
SELECT *
FROM svc_health
WHERE status = 'timeout'Common follow-up questions
Common follow-up questions
- Restrict the result to the past hour for an active incident page. (Adds `AND checked >= NOW() - INTERVAL '1 hour'`, which prunes partitions and tightens the scan.)
- Return one row per service, summarizing how many timeouts each has had. (Switches from a row dump to `SELECT svc_name, COUNT(*) FROM svc_health WHERE status = 'timeout' GROUP BY svc_name`.)
- What if `status` values start mixing casing for timeouts too? (Then `LOWER(status) = 'timeout'` earns its place, and the real fix is a normalization step or a check constraint upstream.)