Stress Testing
The deterministic runtime executes your system design as a step-by-step simulation. Given the same inputs, it always produces the same outputs.
How it works
Section titled “How it works”- Entry points are identified (components with no inbound forward connections)
- Seed requests are injected at entry points
- Each step processes one topological layer of the graph
- Components apply their behavior (passthrough, filter, queue, delay, etc.)
- Output requests are routed to downstream connections
- Backpressure: if a downstream queue is at 80%+ capacity, delivery is delayed by one processing cycle instead of arriving instantly
- Queue overflow drops the oldest request (FIFO) to preserve ordering
- The simulation continues until all requests are consumed or a step limit is reached
- If the estimated duration exceeds 1 hour, time compression scales all timing values proportionally to fit within the cap (see Time compression)
Determinism
Section titled “Determinism”The runtime uses a fixed seed (42) for any randomized behavior (e.g., filter drop rates). This means:
- Same design + same parameters = same results every time
- You can reproduce and debug specific failure modes
- Comparing before/after changes is meaningful
Monte Carlo jitter
Section titled “Monte Carlo jitter”When running Monte Carlo analysis (multiple runs with varied seeds), process times are jittered per component per run. The jitter range scales with graph depth:
- Base jitter: +/-15%
- Deeper topologies (4+ components): jitter increases by 1% per additional layer, up to 25%
- Formula:
0.15 + max(0, 0.01 * (depth - 3)), capped at 0.25
This produces correlated downstream failures that are more realistic than uniform noise.
SLO modeling
Section titled “SLO modeling”After a Monte Carlo run, you can evaluate results against Service Level Objectives. Open the SLO Targets section in the Monte Carlo tab and configure up to three targets:
| Target | Range | Description |
|---|---|---|
| Min Delivery Rate | 0-100% | Minimum percentage of requests that must be successfully delivered |
| Max Dropped | 0+ | Maximum number of requests allowed to be dropped |
| Min Health | 0-100% | Minimum average system health across the run |
Leave a field empty to skip that target. Once configured, every Monte Carlo run is evaluated per-run against your SLO targets:
- Compliance card: Shows the overall pass rate (e.g., “85% of runs met SLO”) with a visual strip of green (pass) and red (fail) blocks, one per run
- Per-run column: The results table gains an SLO column showing pass/fail for each individual run
- Pass criteria: A run passes only if it meets all configured targets simultaneously
SLO targets persist per project and update live when you re-run Monte Carlo.
Cost simulation
Section titled “Cost simulation”If any components on the canvas have monthly cost values set (in the component editor’s Cost section), Monte Carlo runs include a cost breakdown:
| Metric | Description |
|---|---|
| Total Monthly | Sum of all component monthly costs |
| Cost per Delivered | Total monthly cost divided by average delivered requests across runs |
| Cost per Dropped | Total monthly cost divided by average dropped requests across runs (shown only when drops occur) |
The cost analysis card appears below the SLO compliance card in the Monte Carlo tab. This gives a per-request cost perspective on your design: a system that drops more requests costs more per successful delivery.
Runtime panel
Section titled “Runtime panel”Open the Runtime Panel (R key) during simulation to access three tabs:
| Tab | What it shows |
|---|---|
| Overview | Health score, request/processed/lost counts, bottleneck, component table, connection table |
| Stability | Temporal health trend chart, step timeline with per-component detail, fix recommendations (Pro) |
| Stress Test | Quick scenario presets and manual injection controls |
Quick scenarios
Section titled “Quick scenarios”The Stress Test tab provides one-click presets:
| Preset | What it does |
|---|---|
| Baseline | Normal traffic (1x), single burst, no faults |
| Peak Traffic | 5x traffic with steady arrival stream |
| Outage | Kills a random component, normal traffic |
| Slowdown | 3x traffic with steady arrival, injects +3 steps latency on a random component |
Click any preset to instantly configure and enable stress controls.
Manual controls
Section titled “Manual controls”Traffic
Section titled “Traffic”| Control | Range | Description |
|---|---|---|
| Traffic multiplier | 1-5x | Multiplies the seed packet count (total = seeds x multiplier) |
| Arrival pattern | Single burst or every 1-5 passes | How traffic arrives over time |
Seed packets (1-100) are set from the timeline bar at the top. You can type a value directly or use the stepper arrows. The traffic multiplier in the stress panel scales that number.
Fault injection
Section titled “Fault injection”| Control | Description |
|---|---|
| Kill component | Take a component completely offline (drops all requests) |
| Slow down component | Add extra processing delay to a specific component |
| Extra delay | 1-5 additional steps of latency on the slowed component |
Canvas feedback
Section titled “Canvas feedback”During simulation, the canvas shows:
- Queue saturation heatmap - Components tint orange to red as queues fill
- Queue depth badges - Numeric count when buffered items exceed 3
- Connection weight - Pipe thickness scales with request volume
- Bottleneck alerts - Pulsing borders and warning icons on saturated components
- Runtime delta badges - Show requests in (+), dropped (-), and queued counts per step
- Backpressure warnings - Events fire when a queue reaches 80% capacity
- Rate limit drop events - Events fire when requests are dropped due to rate limiting
- Inactive dimming - Components not involved in the current simulation dim to 30% opacity, connections to 15%
Component tooltip
Section titled “Component tooltip”Hover any component during simulation to see live runtime stats:
- Received - Total requests that entered the component across all frames
- Delivered - Total requests that left the component across all frames
- Queued - Current queue depth at this frame
- In transit - Requests currently on connections headed to this component
- Lost - Requests dropped by this component (capacity overflow, filter, rate limit, etc.)
Stats only appear when non-zero.
Status pills
Section titled “Status pills”Colored pills appear above components to indicate state during playback:
| Pill | Color | When it appears |
|---|---|---|
| N delivered | Green | Exit nodes (no outgoing connections) that have processed requests |
| N entered | Blue | Entry nodes (no incoming connections) that have received requests |
| N processing | Amber | Inactive delay components with items in their queue |
| N done | Accent | The currently active component has finished outputting requests |
| N waiting | Accent | The currently active component has items buffered in its queue |
| N lost | Yellow | Requests were dropped (filter, capacity overflow, killed component) |
Pills are cumulative: delivered and entered counts accumulate across steps. Processing pills only appear on components with delay behavior that are not currently the active step.
Stability verdicts
Section titled “Stability verdicts”The Stability tab in the Runtime Panel shows a CI-1T verdict:
| Verdict | Instability Range | Meaning |
|---|---|---|
| Stable | <= 10% | Low variance across steps, consistent behavior |
| Drift | <= 30% | Moderate variance, performance changing over time |
| Volatile | <= 55% | High variance, unpredictable behavior |
| Critical | > 55% | Extreme instability, system breaking down |
Important: CI measures variance and consistency, not correctness. A component that fails consistently (e.g., a killed component that always drops requests) will appear “Stable” because its behavior is predictable. The system overrides verdicts when real problems exist:
- Errors detected: Stable is overridden to Volatile
- Drops detected: Stable is overridden to Drift
Recommendations explain the distinction so you know when low CI hides real failures.
Direction awareness
Section titled “Direction awareness”The runtime respects connection directions:
- Forward connections carry requests from source to target
- Backward connections carry requests from target to source
- Both connections carry traffic in both directions
- None connections are ignored by the runtime