Interactive lab · Infrastructure
A working server-rack model. Break things on purpose, watch one failure cascade into many, then fix it the way a real admin would.
The simulator
Inject a fault and watch the LEDs and the dependency graph change. Click any rack unit or graph node to inspect it — then press Fix and watch recovery climb back up in dependency order. Every reading on this page is simulated.
Fully offline simulation. Nothing here monitors or touches a real server — every LED, latency, and wattage is scripted in your browser.
Fault to inject
The rack
Dependency graph
1 your click goes out2 the database answers3 the answer comes back
Follow your click through the servers and back.
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 — watch the failure fall down the stack.
Every layer above is healthy — each breaks only because of the one below it. The fix runs bottom-up: restart the database, and recovery climbs back in the same order.
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. The Server Room is free to use as often as you like — no account, no sign-up. PlainLogic may introduce optional accounts or paid features in the future, but the core labs are free to use today.
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.