Interactive lab · Infrastructure
What “the server is down” actually means. A working model of a server rack — power, networking, and the services stacked on top. Break things on purpose, watch one failure cascade into many, then fix it the way a real admin would: in dependency order.
Fully offline simulation. Nothing here monitors or touches a real server — every LED, latency, and wattage is scripted in your browser.
The simulator
Inject a fault and watch the LEDs and the dependency graph change. Click any rack unit or graph node to inspect it — the inspector shows what it does, what it depends on, and what depends on it. Then apply the fix and watch the rack recover in dependency order. Every reading on this page is simulated.
Fault to inject
The rack
Dependency graph
Active fault
—
Inspector
Click any rack unit or graph node to learn what it does, what it needs, and what breaks without it.
Service health · simulated telemetry
Event log
One fault at a time, on purpose — real troubleshooting starts by isolating a single change. The fix always runs bottom-up: repair the lowest broken dependency first, and everything above it recovers in order.
Plain-language infrastructure
Seven boxes, four jobs: power in, power out, networking, and the three-layer application with its disks. Everything a small production setup is some version of these.
Uninterruptible power supply. It sits between the wall power and the rack, conditions the incoming mains, and keeps a battery charged — ready to take over in milliseconds when the mains drops. Its only question is always: how many minutes are left?
Power distribution unit: the rack's power strip, usually mounted at the back. It takes the UPS output and feeds every unit through individually metered outlets. One PDU, seven mouths to feed — which is why power is the one dependency literally everything shares.
Connects every unit to the same local network and forwards traffic between them — and its uplink port carries visitor traffic in from the outside world. Kill the uplink and the servers can still talk to each other, but nobody outside can reach the site.
The box visitors actually talk to. It serves the site's pages and assets, but nearly everything dynamic comes from asking the API. Healthy web server, dead database? The site still goes down — it just goes down politely, with an error page.
The middle layer: it takes requests from the web server, runs the application's logic, and reads and writes data through the database. When the database is offline, the API is the first thing to look sick — slow responses, then errors.
Stores the application's data and answers queries from the API. The whole request chain funnels through this one box, which is why it is the classic “one box takes down the site” culprit — and why real databases get replicas and backups.
The disk array the database writes to. Databases assume storage is fast and never full. Fill the disks and the database can still read — but every write fails, and the failure climbs the chain.
Reading a failure
Inject Database offline above and follow along. Each layer is healthy — and each layer breaks because of the one below it.
One box, one fault. The database service stops answering queries — the machine is still powered, the network is fine, the disks are fine. Nothing is listening on its port anymore.
The API server is perfectly healthy, but every query it sends to the database times out. Responses slow down, then start failing. The API didn't break — it was broken by something it depends on.
The web server is healthy too. But with the API erroring, it has nothing good to send visitors — so it serves error pages instead of the site.
From the outside, all anyone sees is the site not loading. “The server is down” — but which server? The fix starts at the bottom of the chain: restart the database, and the recovery climbs back up in the same order. Watch it happen when you press the fix button.
Questions
An uninterruptible power supply sits between the wall power and your equipment with a battery inside. When the mains power cuts out, it switches to battery instantly — fast enough that servers never notice — and keeps everything running for a limited time (minutes, not hours). That window is for riding out blips or shutting down cleanly. Try the power-outage fault above: the site stays up, but the clock is ticking.
A power distribution unit is the rack's power strip, usually mounted at the back of the rack. It takes the UPS output and splits it into switched outlets for every unit, often with per-outlet metering so you can see what each server draws. In the simulator, every unit lists its power draw in the inspector, and everything traces its power back to the PDU.
Because the website is the end of a chain, not a single thing. A visitor's request hits the web server, which asks the API, which asks the database. If the database is offline, the API has nothing to answer with, so the web server has nothing to show — the site is “down” even though the web server itself is perfectly healthy. Inject “Database offline” above and watch the cascade light up in order.
No. This page is a fully offline simulation — there are no network calls, no API keys, and nothing to connect to. The rack, the LEDs, the latencies, and the wattages are all scripted in your browser. It teaches the concepts; it never monitors or touches real infrastructure.
Yes. Like everything in the PlainLogic lab, the Server Room is free to use as often as you like. No account, no sign-up, no paid tier.
Keep exploring
The companion experiment: watch packets hop through switches, a firewall, and a router — then break the network on purpose and find the fault.
The next lab in the series: follow data from raw events to something a dashboard can show.
Games, experiments, useful tools, and the blog — the full bench.