Load tests ZITADEL's OpenID Connect endpoints and health: discovery, keys, and the authorization and token endpoints with their error cases. It shows how sign-in and token issuing scale.
It holds 45 ready-made jobs: 25 single scenarios and an enterprise test plan of 20 stages to run in order, 17 of them with pass/fail targets (SLOs). Each job is a plain request pattern you can change before running.
Scenarios include OIDC discovery document, discovery document (cache bypass), JSON web key set, authorization endpoint (login page or redirect) and silent authentication (prompt=none).
How to load test ZITADEL
Open the template in BLASTA.
Set url, clientId and redirectUri to point at your own ZITADEL system, ideally a staging copy.
Pick a job and choose the rate and duration.
Start the run and watch requests per second, latency percentiles and errors live; the result is saved to your history.
What you set before running
url
Issuer / base URL, no trailing slash
clientId
A test client registered for load testing
clientSecret
A credential, supplied as an environment variable and never typed into the form. Client secret. Read from the OIDC_CLIENT_SECRET env var by the CLI.
redirectUri
A redirect URI registered on that client
scope
Space-separated scopes, URL-encoded
token
A credential, supplied as an environment variable and never typed into the form. A valid access token. Read from OIDC_ACCESS_TOKEN by the CLI.
What SPAs do in a hidden iframe to renew a session. With no session it must answer with a login_required redirect, quickly, and without rendering a page.
Must be rejected with an error page, never redirected (open-redirect check): a 302 to the bad URI would be a vulnerability, so only 4xx and the error page count as success.
Token renewal, the most frequent token call in a long-lived app. If refresh tokens ROTATE, only the first request succeeds and the rest fail with invalid_grant: use a client without rotation.
Enterprise plan, step 1 of 10. One request a second for 30 seconds. Run this first, every time: it proves the address, credentials and headers are right and that the environment is up before any real load is applied. Gate: zero errors. Reference request: authorization endpoint (login page or redirect).
Step 2 of 10. About a fifth of normal traffic for 5 minutes: the uncontended latency of this request. Every later result is judged against it, so record p50 and p95. Gate: at most 0.5% errors and the default latency targets. Reference request: authorization endpoint (login page or redirect).
Step 3 of 10. Normal busy-hour traffic for 10 minutes. The rate is the reference job's rate: raise it to your measured production peak-hour rate. This is the run that proves (or breaks) your SLO. Gate: at most 1% errors, p95 and p99 inside the targets. Reference request: authorization endpoint (login page or redirect).
Step 4 of 10. Twice the average for 10 minutes: the busiest hour of the year plus headroom. Latency may rise, but must stay in SLO; if it does not, you have no headroom. Gate: at most 2% errors, latency targets doubled. Reference request: authorization endpoint (login page or redirect).
Step 5 of 10. Ramps to four times average over 10 minutes, then holds for 2. Finds where it degrades and HOW: gracefully (latency rises, errors stay low) or badly (errors, timeouts, crashes, restarts). Observation only, no gate. Reference request: authorization endpoint (login page or redirect).
Step 6 of 10. Reaches ten times average within 10 seconds and holds for 2 minutes: a campaign email, a news link, a failover. Checks autoscaling, queue limits and load shedding. Gate: at most 5% errors, because shedding load is acceptable and crashing is not. Reference request: authorization endpoint (login page or redirect).
Step 7 of 10. Run IMMEDIATELY after the spike, at average load for 5 minutes. Latency and errors must return to the baseline from step 2. If they do not, something is stuck: queues, connection pools, GC, an autoscaler cool-down. Gate: same as average load. Reference request: authorization endpoint (login page or redirect).
Step 8 of 10. One hour of steady load. Finds leaks and slow decay in memory, connections, file descriptors, disk, log volume and cache churn. Watch the resource graphs: any line that climbs and never flattens is a finding. Gate: at most 0.5% errors. Reference request: authorization endpoint (login page or redirect).
Step 9 of 10. Ramps to twenty times average over 20 minutes. Stop it when errors pass about 5%: the rate at that moment is your ceiling, and ceiling divided by peak is your capacity margin. Use a production-like environment, never production. Reference request: authorization endpoint (login page or redirect).
Step 10 of 10. Average load for 15 minutes. About 5 minutes in, cause the event you are testing: kill a pod or node, fail over the database, roll out a new version, drain a zone. Errors in the window are your real availability loss. Gate: at most 1% errors overall; read the time series for how long the dip lasted. Reference request: authorization endpoint (login page or redirect).
Sends Connection: close, so every request pays for a new TCP and TLS handshake: the cost for clients that do not reuse connections (scripts, some mobile SDKs, health checkers). Shows load balancer and TLS termination limits. Reference request: authorization endpoint (login page or redirect).
Same request identified as a search crawler. Tests WAF and bot-management rules and whether crawlers get cached or origin responses. Crawlers can easily be a third of all traffic. Reference request: authorization endpoint (login page or redirect).
Adds a 4 KB Cookie header, like a logged-in user with many tracking cookies. Proxies and servers reject headers around 8 KB, so this shows how close you are to that limit. Reference request: authorization endpoint (login page or redirect).
A fleet of synthetic monitors checking the URL with HEAD requests every 30 seconds from 20 locations, plus load balancer probes. Cheap each, constant in total. Reference request: authorization endpoint (login page or redirect).
Everyone in the company signs in within a minute of starting work. Ramps login starts to eight times normal over 60 seconds. The identity provider is the one system every other system depends on, so this is the most important identity test. Reference request: authorization endpoint (login page or redirect).
Many services were started together, so their tokens expire together and they all ask for new ones in the same second. Jumps token requests to ten times normal in 10 seconds. Reference request: token: client credentials. This job WRITES or creates data on every request: staging only, and expect a lot of rows.
An API gateway that introspects opaque tokens adds one introspection call to every business request, so the identity provider carries the whole API's traffic. Three times normal for 10 minutes. Reference request: token introspection.
After a signing key rotates, every service that validates tokens refetches the key set at once. Twenty times normal for 90 seconds; this should be a cache hit at the edge. Reference request: JSON web key set.
Ten times the normal rate of failed client authentication for 2 minutes, the shape of a credential-stuffing attack. The provider must stay responsive for real users, rate-limit or lock the attacker, and not spend expensive hashing on each attempt. Run a normal login in parallel to confirm it keeps working. Staging only: it can lock the client. Reference request: token: wrong client secret.
Frequently asked questions
What does the ZITADEL load test cover?
The ZITADEL template has 45 jobs: 25 single scenarios and an enterprise test plan of 20 stages (smoke, baseline, load, stress, spike, soak, breakpoint and failover window). Scenarios include OIDC discovery document, discovery document (cache bypass), JSON web key set and authorization endpoint (login page or redirect). 17 of them have pass/fail targets (SLOs), so a run can be judged against limits you set.
How do I load test ZITADEL with BLASTA?
Open the template in BLASTA and set url, clientId and redirectUri, then pick a job and start it. Results stream live: requests per second, latency percentiles and errors, and the run is kept in your history. To run from the command line, use blasta preset new zitadel with your address.
Is it safe to run the ZITADEL load test against production?
Of the 45 jobs, 37 are read-only, 1 write data and 7 change state. Run the writing and state-changing jobs against a staging system, never against production data. Only test systems you own or have permission to test.
Set up a target above and press Start test. Charts and numbers appear here as the test runs.
Load generator resources
CPU used by BLASTA % of capacity
RAM used by BLASTA
Requests per second
Latency p95 lower is better
Response time
Status codes
Errors
Pick a template
Ready-made jobs for common systems. Search by system, protocol or what you want to test
(wordpress, saml, redis, spike, login storm…), pick a job, and it opens on the Test page ready to run.
You are browsing as a visitor: you can read every template and job. Sign in or create an account to use them.
No templates match
Try a shorter search, or a system name such as keycloak, postgres or soap.