Know where your system breaks, before your users find out.
Replicate the infrastructure you run, play real recorded traffic through it, and see which part gives out first, the second it happens, and what it takes down with it.
A load test tells you it got slow. It doesn't tell you why.
Dashboards show symptoms after the fact. Diagrams show what you meant to build. Neither shows how this exact system behaves when a server dies at the worst possible moment.
Most capacity decisions are made from a mix of vendor numbers, a load test against staging, and experience. That works until the failure you didn't test for. Then the questions start: which part saturated first? Was it the server that died, or the one that took its traffic? Did the database slow everything else down?
InfraForge answers those questions before you ship. You rebuild your system as it really is, play a recording of real traffic through it, inject the failure you're worried about, and read what happened second by second. Nothing is estimated after the fact; every number on the screen is the recorded value at that second.
Replicate, replay, read.
Three steps, each one honest about what it knows. If a value wasn't recorded, InfraForge shows it as unknown, never as zero.
Replicate the system you actually run.
Place a load balancer, app servers and a database. Size each one, connect them the way traffic really flows, and set the limits you have in production.
| lb | Load balancer |
| app-1, app-2 | 2 × virtual machine |
| db | Database |
Replay real recorded traffic.
468,000 requests per hour, steady, 80% reads, medium payloads, applied second by second. Then inject the fault you're worried about: here, app-2 crashes at second 60 and stays down for 30 seconds.
Read where it broke, and why.
Every component reports its load, CPU and health every second. When something fails, you get the chain of events that led to it, read straight from the recording.
- Requests
- 130 rps
- CPU
- 100%
- Full since
- second 63
app-2 crashed at second 60; the balancer sent app-1 its share too.
Ninety seconds, one crash, every second on the record.
The run below is the challenge “Lose an app server”: 468,000 requests per hour, steady, 80% reads, medium payloads. Scrub through it and watch the bench.
The server that died wasn't the one that failed the test.
app-2 crashing was the experiment. The real finding is what the remaining system did next.
- 59s
Two servers, plenty of room
The balancer sends 65 rps to each app server. Both sit near 43% CPU.
- 60s
app-2 crashes
Its process stops. From the next second it answers nothing and its cables drain.
- 61s
app-1 takes everything
Its traffic doubles from 65 to 130 rps and its CPU jumps to 86.3% in one second.
- 62s
The database runs hot
Its CPU reaches 95.4% at 156 rps.
- 63s
app-1 is saturated
CPU hits 100%. One server was never enough for this traffic; two only looked like it.
Start with the parts every system has.
Each component behaves like the real one under load: it saturates, queues, fails and recovers. New components arrive only once they are realistic.
| Component | What is modelled | Status |
|---|---|---|
| Load balancer | How requests are split across targets, and where they go when a target stops answering. | Available |
| App servers | Requests, CPU and memory on each instance, every second, sized like real machine types. | Available |
| Database | Query load and CPU, and the second it saturates. | Available |
| Cache | What it absorbs, and what reaches the database when it misses or fails. | Available |
| Queues and workers | Backlog, consumers and retries. | Planned |
| Autoscaling groups | New instances, their warm-up time, and the config they inherit. | Planned |
| CDN and object storage | Edge hits, origin load and transfer. | Planned |
Every second, for every component.
These are the values InfraForge records. Anything it cannot measure yet is labelled as such, so you never mistake a gap for a zero.
Requests per secondRecorded
How much traffic each component handles, and how it shifts when something fails.
CPURecorded
How busy each component is. Sustained 100% means requests are waiting.
MemoryRecorded
How much each instance holds, per second.
HealthRecorded
Healthy, under pressure, saturated or failed, with the second it changed.
Latency p50 · p95 · p99Coming with the new engine
What a typical request, and your slowest requests, experience.
Monthly costComing with the new engine
What the setup costs per month at real provider prices, so you can weigh headroom against spend.
Break it on purpose, on a timeline.
Pick what fails, when, and for how long. The recording shows the rest of the system's response.
| Failure | What happens | Where to see it |
|---|---|---|
| Server crash | The process stops; the balancer must route around it. | Lose an app server |
| CPU pressure | Extra load lands on one server for a set time. | Headroom under CPU pressure |
| Cache failure | The cache goes down and the database takes every read. | When the cache fails |
| Traffic bursts | Load doubles in short bursts. | Survive the peak |
Not a load test. Not a diagram.
InfraForge sits between the tools you already use: it runs like a test, reads like a diagram, and explains like a post-mortem.
| Load testing | Diagram tools | InfraForge | |
|---|---|---|---|
| Needs the real system running | Yes | No | No |
| Shows behaviour under load | Yes | No | Yes, recorded per second |
| Explains why something failed | No | No | Yes, as a chain of events |
| Injects failures on a timeline | Sometimes | No | Yes |
What engineers ask first.
Short answers. The docs go deeper.
Is this a simulation or a real deployment?
A simulation. Nothing is deployed to your cloud account. InfraForge models each component's behaviour under load and records every second, so you can study a failure without causing one.
Where does the traffic come from?
From recorded workloads. The run on this page is 468,000 requests per hour, steady, 80% reads, medium payloads. The same recording is replayed every time, so runs are repeatable and comparable.
How realistic are the numbers?
Each value is recorded from the engine at that second, never filled in afterwards. Where a value isn't measured yet, such as latency percentiles today, it is shown as unknown rather than as zero.
Which clouds and components are supported?
Load balancers, app servers, a database and a cache are available now. Queues, autoscaling groups, CDN and object storage are planned and will be added only when they are realistic.
Do I need to install anything?
No. InfraForge runs in the browser.
What does it cost?
It is free during early access.
Replicate one system you run, and break it on purpose.
It takes a few minutes to build. The recording takes 90 seconds.