Record the flow.
Run the load.
Find the cause.
Atlas turns a click-through in your browser into a working test plan, runs it across as many generators as you need, and shows you the request that broke — not just the percentage that failed.
Apache JMeter today, k6 coming. Fully managed by us, deployed into your own cloud, or run on your own machines — your choice, and you can mix them in one test.
“Order submission starts failing at 16,400 users — the database connection pool saturates first.”
Running in production
Three steps, and none of them is “learn a scripting language”.
Most load-testing projects die in week one, in the scripting. Atlas starts you past it.
Click through it in a browser
A real Chrome window opens. You do the journey — sign in, search, add to basket, pay. Atlas watches, groups each interaction into a named transaction, and writes the test plan.
The session tokens and ids that normally eat two days of scripting are found and wired up automatically.
Pick a number and press Run
Choose how many generators, or a cluster that spins containers up for the run. Atlas powers them on, distributes the files, splits the data and starts the test. There is no deploy step to remember.
When the run ends, everything it started is shut back down and metered.
Find the request that broke
Live numbers from five seconds in. Then drill: which transaction, which request, which error — with the full response body the server actually sent back.
“12% errors” is a symptom. Atlas keeps the evidence.
Everything a load test needs, and nothing you have to assemble yourself.
Browser recorder
Record a journey and get a runnable plan with transactions named after what you actually did, and dynamic values correlated for you.
Flexible infrastructure
Fully managed generators, machines in your own cloud account, containers on demand, or boxes in your building. One test can use several at once.
Root-cause evidence
Every distinct failure stored once with its full request and response, plus generator CPU and memory so you can rule out the test rig itself.
Test-data distribution
Big data files split across generators so every virtual user gets its own row — byte-for-byte, with the header question answered from your test plan rather than guessed.
CLI and CI gates
Run from a pipeline with pass/fail thresholds, exit codes and JUnit output. Or save a configuration and let it run on a schedule.
Open test formats
Plans are ordinary Apache JMeter files that open anywhere. k6 soon
The two days you usually lose to correlation.
Anyone who has scripted a real application knows the part that hurts: the CSRF token, the session id, the order number the server invents halfway through. Replay them literally and every virtual user fails on request four.
Atlas correlates on evidence. A value your browser sent is only parameterised if it can be found in something the server said earlier — and the kind of response decides how it is extracted: JSON gets a JSON path, a hidden form field gets a CSS selector, a header gets a regular expression.
Each extraction gets an assertion, so if the pattern ever stops matching, the run tells you
instead of quietly sending the literal NULL.
found in 02 · POST /session → JSON $.csrf
replaced in 03, 04 → ${_csrfToken}
A number tells you something broke. Atlas tells you what.
Live from five seconds in, then drill from the total down to a single request: per thread group, per transaction, per call, with min, max, mean and p50 through p99.
Every error kept once, in full
Request, response code and response body — deduplicated per type so a million failures do not become a million rows.
Generator health alongside
CPU and memory per generator, so you can tell a saturated test rig from a saturated application. That mistake invalidates more results than any other.
Run-to-run history
Every run kept with its name, duration and peak users, so a release can be compared with the one before it. Export to Excel with the chart embedded.
response body
{"error": "connection pool exhausted",
"pool": "orders-db", "waiting": 240}
Stored once, with the request that produced it — not counted and thrown away.
Let us run it, run it yourself, or do both in the same test.
Most platforms pick one of these for you. The decision usually belongs to your security team, your budget and your architecture — not to your testing tool.
We run the generators
Nothing to install and no infrastructure to own. Pick how many generators you want, press Run, and we start and stop them for you.
The quickest way to a first result — usually the right choice for a public-facing site.
Your AWS or GCP account
Generators — or the whole platform, dashboard and data included — deployed inside your own account, in the region you choose, under your own policies.
Containers can be allocated for the run and destroyed at the end, so you pay for minutes.
Machines behind the firewall
A machine you already own becomes a generator with one command. It dials out on 443 — no inbound ports, no VPN, no SSH access for us.
This is how you load-test an application that has no public address at all.
And one test can use all three at once.
Drive load from our cloud and from inside the building in the same run, and compare what an external customer experiences with what someone on the internal network does — in a single set of numbers, on one chart.
Two million rows, twelve generators, no duplicates.
Realistic load needs realistic data: distinct accounts, distinct ids, distinct search terms. Hand the same file to every generator and you get the same user hammering the same record from twelve directions.
Atlas splits the file round-robin so each generator gets its own slice, and replicates the header into every one. Records are cut out of the raw bytes, so column order, quoting, escaped quotes, encoding, embedded newlines and line endings all survive exactly as you uploaded them.
Whether row one is a header is read out of your test plan, not guessed — because guessing wrong either injects a junk row into every slice or silently drops a real one.
GEN 01
166,667
GEN 02
166,667
GEN 03
166,666
… 12
PRESERVED EXACTLY
2014,265,"ירושלים, מרכז"
2014,1,"Tel Aviv"
Column order, quoting and encoding come out the way they went in — never re-serialised through a parser.
A quality gate, not an event before release.
One command runs a test, waits for it, checks your thresholds and exits with a code your pipeline already understands. Results publish as JUnit, so your build server renders them with no plugin.
The CLI holds no infrastructure credentials — it talks to the same API as the browser, so quotas, permissions and metering all apply exactly as they do in the interface.
$ npm install -g @cloudbeat/atlas-cli
$ atlas run --project checkout --servers 4 \
--gate 'p95 < 800' --gate 'error_rate < 1' \
--junit results.xmlexit 0 every threshold met
exit 1 a threshold was breached
exit 3 the run failed or timed out
Where Atlas is going next.
Listed here rather than mixed into the features above, because none of it is running yet. Tell us which of these would matter most to you.
AI analysis of a run
A written read of what happened: where the system started to bend, which transaction gave way first, and what changed since the last run — instead of you reading percentiles across two tabs.
Root-cause suggestions
Errors clustered by what they have in common and matched against the response bodies already stored, to propose the likely cause rather than leave you correlating by eye.
k6 scenarios
JavaScript test plans running on the same fleet, in the same dashboard, next to your JMeter runs — so the choice of tool stops being a choice of platform.
Agent-native access
An MCP server alongside the CLI, so a coding agent can start a test, wait for it and read the results itself — and performance becomes something an agent checks before opening a pull request.
Start free. Scale on infrastructure, not on a per-user tariff.
How many virtual users you can drive is a function of the generators behind the test — so turning the load up does not change the shape of your bill.
Try it
Record a scenario, run it on a managed generator, read the results. No card.
— Browser recorder and CLI
— [N] managed generator hours
— [retention] of run history
Managed
We run the infrastructure. You pick how many generators each test gets.
— Unlimited virtual users
— Scheduling and CI gates
— Projects, teams and quotas
— [YOUR PRICE]
Your infrastructure
The whole platform deployed in your cloud account or data centre, installed and supported by us.
— Everything in Team
— Your data never leaves your estate
— Air-gapped installations
— Support agreement [terms]
[Tier boundaries and prices are placeholders — the free tier in particular needs a real definition before launch.]
What people ask first.
Do I need to know JMeter?
No. Record the journey in a browser and Atlas writes the plan. If you do know JMeter, the output is an ordinary .jmx you can open and edit like any other — nothing is locked in a proprietary format.
We already have JMeter scripts. Do they still work?
Yes — upload the plan and its data files and run it. Plans written on Windows usually need their file paths made relative and GUI listeners switched off; that is part of onboarding.
How many virtual users can I run?
There is no licensed ceiling — it depends on your generators. As a planning figure, one [SPEC] generator sustains roughly [N] users on a typical HTTP scenario, and you add generators from there.
Can we test something that is not on the internet?
Yes. Install a generator on a machine inside the same network and it drives the application directly. It connects outbound only, so nothing has to be exposed and we never need inbound access.
When is k6 support arriving?
It is in development and not yet released.
Does it fit into our pipeline?
The CLI installs from npm and runs anywhere Node does. It takes thresholds, returns standard exit codes and writes JUnit XML, so any build server can gate a merge on it without a dedicated plugin.
Record your first scenario in the next ten minutes.
Or book half an hour and we will run a test against a system of your choosing, on infrastructure of your choosing, while you watch.
$ npm i -g @cloudbeat/atlas-cli
$ atlas record example.comA browser opens. Click through your journey. You get a test plan.