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.
Overview panel
Section titled “Overview panel”Open the Overview panel from the left toolbar during simulation. It contains three tabs:
| Tab | What it shows |
|---|---|
| Overview | Health score (filter drops excluded from penalty), request/processed/filtered/lost counts, bottleneck, component table, connection table |
| Stability | Temporal health trend chart, step timeline with per-component detail, fix recommendations (Pro) |
| Monte Carlo | Multi-run analysis with jittered seeds, SLO targets, cost breakdown (Pro) |
Stress test panel
Section titled “Stress test panel”The stress test controls live in a separate floating panel, opened from the Overview panel. It provides quick scenario presets and manual injection controls.
Quick scenarios
Section titled “Quick scenarios”The stress test panel 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-1000) are set from the timeline bar at the bottom. 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
- Filtered - Requests intentionally removed by this component (filter-mode only, shown in purple)
- Lost - Requests dropped by this component due to failures (capacity overflow, rate limit, circuit breaker, retry exhaustion)
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 filtered | Purple | Requests intentionally removed by filter-mode components (by design, not failures) |
| 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 lost to actual failures (capacity overflow, killed component, rate limit) |
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 Overview 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 (only counts actual failure drops, not intentional filter removals)
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