Configuration
Basic Parameters
Simulation Results
Configure your parameters above and hit Simulate to see results.
Export
Source Config Export
Save or share your simulation setup as YAML.
Target Config Export
Generate a deployable manifest for your platform.
Load Test Export
Generate a ready-to-run load test script for your traffic scenario.
What is scalings.xyz?
scalings.xyz is an interactive autoscaling simulator. It lets engineers configure autoscaling parameters, select a traffic pattern, and run a discrete-time simulation to visualize whether their scaling policy can handle the load. Once you've found a config that works, export deployment manifests for your platform and load test scripts to validate against real infrastructure.
Architecture: the page you're looking at runs 100% in your browser — no backend, no API calls, no telemetry. Configs you build here never leave your tab. The optional MCP server at mcp.scalings.xyz is the one exception: when AI tools (Claude Desktop, Cursor, Claude Code) call simulation tools, those calls execute on a Vercel serverless function. Same engine, just headless. If you only use the website, nothing leaves your browser.
Use scalings.xyz from your AI coding tool (MCP)
scalings.xyz exposes a Model Context Protocol server so AI clients can run simulations programmatically. Note: unlike the browser UI, MCP tool calls execute server-side on a Vercel serverless function (stateless, no auth, no user data stored).
- Endpoint:
https://mcp.scalings.xyz/mcp(Streamable HTTP) - Tools:
run_simulation,compare_simulations,list_presets,get_simulation_url,describe_parameters
Connect:
- Claude Code:
claude mcp add --transport http scalings https://mcp.scalings.xyz/mcp - Claude Desktop (
claude_desktop_config.json) or Cursor (.cursor/mcp.json):{ "mcpServers": { "scalings": { "url": "https://mcp.scalings.xyz/mcp" } } }
Full tool reference: docs.md · source on GitHub.
When to use it
- Prioritize optimizations — Is it worth cutting pod startup time from 30s to 10s? Would faster metric delivery help more? Or is simply overprovisioning cheaper? Change one parameter, compare runs, and see exactly how many dropped requests each option saves you.
- Set optimization targets — Don't guess what your startup time or cooldown "should" be. Simulate a range of values against your actual traffic pattern and pick the one that balances cost vs. reliability.
- Validate before deploying — Test a new HPA config, ASG policy, or MIG setup against realistic traffic patterns before it hits production.
- Post-incident analysis — Replay a traffic spike that caused an outage. Tweak the scaling config until the sim shows zero drops, then export the fix.
- Capacity planning — Model upcoming events (product launches, seasonal traffic) to figure out min replicas, max replicas, and cost ahead of time.
- Chaos engineering — Schedule pod failures at specific times to test how your scaling policy recovers from node outages or AZ failures during load.
- Load test generation — Export ready-to-run load test scripts (k6, Gatling, Locust, JMeter, Artillery) that reproduce your simulated traffic pattern against a real endpoint. Validate that your infrastructure handles the load before going live.
Supported Platforms
- Kubernetes HPA — Horizontal Pod Autoscaler
- AWS ASG — Auto Scaling Group
- GCP MIG — Managed Instance Group
- Custom / Generic — Any autoscaler
Parameters Reference
Basic Parameters:
min_replicas— Floor for scale-down (default: 2)max_replicas— Ceiling for scale-up (default: 50)scale_up_threshold— Utilization % that triggers scale-up (default: 70%)scale_down_threshold— Utilization % that triggers scale-down (default: 30%)startup_time— Seconds for a new pod to become ready (default: 30s)capacity_per_replica— Max RPS a single pod can handle (default: 100)
Advanced Parameters:
metric_observation_delay— Lag before autoscaler detects changes (default: 15s)cooldown_scale_up/cooldown_scale_down— Stabilization windowsnode_provisioning_time— Time to spin up a new node (default: 120s, 0=pre-provisioned)cluster_node_capacity— Max nodes in the cluster (default: 20)pods_per_node— Max pods that fit on a single node (default: 10)graceful_shutdown_time— Seconds a terminating pod keeps serving (default: 10s)scale_up_step/scale_down_step— Pods added/removed per event (default: 1)cost_per_replica_hour— USD per pod-hour for cost estimation (default: $0.05)
Chaos Engineering:
pod_failure_rate— Random failure percentage per tick, 0-100 (default: 0)random_seed— Seed for reproducible chaos; 0 = non-deterministic (default: 0)failure_events— Scheduled pod kills: array of{time, count}objects
Traffic Patterns
- Steady — Constant RPS. Params:
rps - Gradual Ramp — Linear increase. Params:
start_rps,end_rps - Spike — Sudden jump. Params:
base_rps,spike_rps,spike_start,spike_duration - Wave — Sinusoidal. Params:
base_rps,amplitude,period - Step Function — Discrete steps. Params:
steps[{rps, duration}] - Custom — User-defined. Params:
series[{t, rps}]
YAML Config Schema
# scalings.xyz simulator config v1
version: 1
name: "Black Friday load test"
platform: kubernetes-hpa
simulation:
duration: 600
tick_interval: 1
scaling:
min_replicas: 2
max_replicas: 50
scale_up_threshold: 70
scale_down_threshold: 30
capacity_per_replica: 100
startup_time: 30
scale_up_step: 1
scale_down_step: 1
advanced:
metric_observation_delay: 15
cooldown_scale_up: 60
cooldown_scale_down: 300
node_provisioning_time: 120
cluster_node_capacity: 20
pods_per_node: 10
graceful_shutdown_time: 10
cost_per_replica_hour: 0.05
chaos:
pod_failure_rate: 0
random_seed: 0
failure_events:
- { time: 120, count: 3 }
traffic:
pattern: spike
params:
base_rps: 200
spike_rps: 2000
spike_start: 120
spike_duration: 60
URL Hash API
Share a pre-configured simulation via URL:
scalings.xyz/#config=<base64-encoded-json>
The config parameter is a base64-encoded JSON object matching the SimulationConfig schema. Add &autorun=true to auto-run the simulation on page load.
AI agents and scripts can construct these URLs programmatically to link users directly to a pre-configured simulation.
Export Types
Source Config Export — Saves/shares the full simulation scenario (YAML). Use for version control and sharing with teammates.
Target Config Export — Generates a deployable manifest for your platform (K8s HPA YAML, AWS CloudFormation, GCP Terraform).
Load Test Export — Generates a ready-to-run load test script that reproduces your simulated traffic pattern against a real endpoint. Supports five frameworks:
- k6 — Modern JavaScript-based load testing by Grafana. Uses
constant-arrival-rateorramping-arrival-ratescenarios. - Gatling — JVM-based load testing. Generates a Java simulation class with injection profiles.
- Locust — Python-based load testing. Generates a
HttpUserclass with optionalLoadTestShapefor non-steady patterns. - JMeter — Apache JMeter JMX format. Uses standard Thread Groups for steady traffic and the Ultimate Thread Group plugin for dynamic patterns (spike, wave, step, custom).
- Artillery — Node.js YAML-based load testing. Maps traffic patterns to Artillery phases.
Generated scripts include the simulation share URL as a comment, so recipients can trace back to the original scalings.xyz scenario. Configure the target URL, HTTP method, headers, and request body before generating. Template variables ($randInt, $randString, $uuid, $timestamp, $randFloat, $randomEmail) are translated to each framework's native random-data idioms.