"Unplug it and see who yells."
Imagine you're cleaning out an office and you find a power strip with 10 cables plugged in. You don't know what any of them connect to. The safest thing to do is trace each cable. But if you're in a hurry, you might just unplug the strip and wait to see if anyone complains. That's the Scream Test.
The Scream Test is the oldest trick in the SysAdmin book. When you cannot determine who is using a server — because logs are missing, documentation was never written, and the original engineers have left — you simply turn it off (or disconnect it from the network). If Slack explodes with angry users, you know it's important. You turn it back on immediately, document the dependency you just discovered, and try a more surgical approach.
When It's Justified and When It Isn't
The Scream Test has a brutally honest trade-off profile:
| Dimension | Assessment |
|---|---|
| Effectiveness | 100% — zero false negatives. If something breaks, you found a real dependency. |
| Safety | Low — can cause production outages, data corruption, or cascading failures. |
| Trust impact | High — developers lose confidence in the Platform team's judgment. |
| Documentation value | High — forces hidden dependencies into the open. |
When it's acceptable: Non-production environments (dev, staging), systems with no external traffic, or infrastructure that has shown zero activity in observability tools for 90+ days.
When it's not acceptable: Any system with production traffic, any system involved in financial transactions, authentication, or data pipelines, and any system where you haven't first exhausted observability options like log analysis, network flow data (e.g., VPC Flow Logs), or distributed tracing.
Interviewers sometimes ask: "How would you figure out if a legacy service is safe to decommission?" The wrong answer is "I'd just turn it off and see what happens." The right answer walks through a layered observability approach first: check access logs, network traffic metrics, distributed traces, and dependency graphs. Mention the Scream Test only as a last resort for non-production systems, and explain why you'd prefer a brownout strategy for anything touching production.