Performance and reliability testing,
because availability is a control.
Run API load tests and frontend audits against thresholds you set, and the results land as evidence rather than as a screenshot in a deck, which is what the resilience requirements in DORA and NIS2 actually ask you to produce.
What it does
- API load tests with a full request builder
- Latency percentiles measured against SLO thresholds
- Lighthouse scoring for the frontend
- Status-code distribution and network phase breakdown
- Scheduled, on deploy, or on demand, with CSV export
Resilience is an evidenced obligation now
DORA and NIS2 moved availability out of the engineering backlog and into the regulated column. Both expect testing that happened, against thresholds that were set in advance, with results somebody can inspect afterwards.
A load test whose output lives in a terminal scrollback satisfies none of that. Running it as a control means the threshold, the run and the outcome are all recorded, and the record is the evidence.
Percentiles, against a number you chose
Mean latency hides the experience that generates complaints. A p50 of 112ms and a p95 of 480ms is a service that is fast for most requests and unacceptable for a meaningful minority, and only one of those figures predicts the support ticket.
So runs report percentiles against an SLO threshold you set beforehand. Declaring the number first is what makes the result a pass or a fail rather than a figure to be interpreted after the fact.
The frontend counts
Availability arguments usually stop at the API, but the thing a user waits for is the page. Lighthouse scoring runs alongside the API tests so both sides are measured, and status-code distribution and network phase breakdown are kept so a regression can be attributed rather than guessed at.
Runs can be scheduled, triggered on deploy, or run on demand, and export to CSV for whoever wants to do their own analysis.
Where this sits
This is one engine of eleven on a single control graph, which is why a result produced here reaches every framework that asks for it instead of being gathered again under another heading. The platform overview shows the other ten, and coverage lists the regimes they answer.
Related reading: the SDK and CI gate.
The things people ask us
Why does a compliance platform run load tests?
Because DORA and NIS2 treat resilience as an evidenced obligation. Both expect testing that actually happened against thresholds set in advance, with inspectable results, which a test whose output lives in a terminal cannot provide.
What is measured?
Latency percentiles against your SLO thresholds, status-code distribution, and a network phase breakdown for the API, plus Lighthouse scoring for the frontend. Percentiles rather than means, because the mean hides the requests that generate complaints.
When do tests run?
Scheduled, on deploy, or on demand. Results export to CSV, and each run is recorded against the threshold that was set before it, which is what makes the outcome a pass or a fail rather than a number to interpret afterwards.
Does a failed test affect compliance readiness?
Yes. It is a control result like any other, so it moves the relevant framework requirements and writes to the evidence ledger, including the failure, not only the eventual pass.
Can we test APIs behind authentication?
Yes. The request builder handles headers, bodies and auth, so the endpoints you actually care about can be tested rather than only the public ones.
Your next audit could be a link.
Thirty minutes. We connect one cloud account live and show you real evidence landing in the ledger before the call ends.