Load testing for every narduk app
Declare an HTTP plan for an owned target, submit it through the authenticated API, and inspect the result.
Config/load-plan.json
{
"version": 1,
"app": "example-app",
"targets": {
"preview": "preview.example.com"
},
"scenarios": [
{
"id": "home",
"weight": 3,
"method": "GET",
"path": "/"
},
{
"id": "health",
"weight": 1,
"method": "GET",
"path": "/api/health"
}
],
"profiles": {
"smoke": {
"stages": [
{
"durationS": 60,
"rps": 5
}
]
},
"baseline": {
"stages": [
{
"durationS": 60,
"rps": 50
},
{
"durationS": 300,
"rps": 50
}
]
}
},
"thresholds": {
"p95Ms": 400,
"errorRate": 0.01
}
}Illustrative result
Illustrative result — not a measured run
preview.example.com · smoke · 5 req/s for 60s
p95 212ms (limit 400ms) · errors 0.00% (limit 1%)
Status: passWhat a run gives you
A declarative plan and a result that records latency, errors and the target build header when available.
- Open-model arrival ratePlans set requests per second, so a slow server cannot quietly lower the load it is measured under.
- k6 on Cloudflare ContainersEach run is a k6 script generated from your plan, in containers started for that run and stopped after it.
- Every second, merged percentilesEach second is recorded per scenario. Run percentiles come from merged scenario histograms, and live results are polled.
- Explicit pass or failThe API records pass, fail or aborted for each finished run. Integrations can use that status after polling the result.
- Aware of rate limits429s are counted separately from other HTTP errors, so you can identify throttling in a run.
- GuardrailsVerified public hostnames only, capped rate and duration, and a kill switch when sustained request failures exceed its limit.
Access: estate-internal
loadtest.dev runs load for Narduk Enterprises apps today. Sign in with your estate account; there are no public sign-ups or paid plans.