Your platform copes with the traffic of an ordinary Tuesday. The question is what happens on campaign day, on enrolment day, or on the day someone decides to knock it over. And above all: what breaks first, because that is not guessed, it is measured.
Three different questions
Load
How much can it take?
We raise load progressively until response times degrade. That number is your real capacity, not the one in the datasheet.
Stress
How does it break?
We push beyond the limit. What matters is whether it degrades gracefully or collapses in a cascade, dragging down services nobody had connected.
Resilience
How does it recover?
What happens when load drops: whether it recovers on its own, how long it takes and whether any data is lost along the way.
What we test
Web applications and APIs with scenarios that reproduce real usage, not flat requests against the home page.
Infrastructure: load balancers, application servers, queues and databases, to locate the specific bottleneck.
Scaling: whether autoscaling reacts in time or arrives after the user has left.
Denial-of-service resistance: application layer and network layer, within an agreed scope and always in a controlled environment.
Behaviour of the protections: what your WAF or CDN does under pressure and whether it blocks legitimate users.
How we work
1
Objectives and metrics
What volume you want to sustain, at what acceptable response time and in what scenario. Without a numeric target there is no test, only curiosity.
2
Scenario modelling
We reproduce your users’ real journeys, with realistic proportions between browsing, searching and operations that write to the database.
3
Progressive execution
From low to high, with monitoring at every layer to see what saturates first.
4
Limit analysis
We identify the exact limiting component and why: CPU, memory, database connections, locking or configuration limits.
5
Report and recommendations
With the degradation curve, the breaking point and what to change to move it.
6
Re-test
After the adjustments we repeat to verify the improvement with data.
What you get
Real maximum capacity at acceptable response times.
Breaking point and the system behaviour beyond it.
Identified bottleneck, with the monitoring evidence that proves it.
Concrete configuration or architecture recommendations, prioritised by cost-to-improvement ratio.
Before and after comparison once the adjustments are made.
Who does the work. The same team that audits, not an account manager. Governance, risk and compliance: CISSP, CISM, ISO 27001 Lead Auditor, ENS and Risk Analysis (CCN), certified DPO, CCSP and CDPP (ISMS Forum) and PMP (PMI). On the technical side: OSCP, CRTO II and eWPTX, ranked in the top 1% of the CCN-CERT Atenea platform. We have run compliance projects for crypto exchanges, universities and public administrations.
Questions we get asked
Can it be done in production?
It can, with an agreed window, stop criteria and your team present. But whenever an equivalent environment exists, it is better to start there and leave production for a final, contained validation.
Is this a security audit?
It is an availability test, which is one of the three classic security dimensions and the one most often forgotten. The Spanish ENS requires it explicitly and DORA places it at the centre of operational resilience.
We are on cloud with autoscaling. Do we need it?
More so, for two reasons: autoscaling takes time to react and that delay is noticeable, and it is worth knowing what a traffic spike will cost you on the invoice before it arrives.
Do you test denial of service too?
Yes, in a controlled environment, within an agreed scope and notifying your provider where appropriate. Never against third-party infrastructure without express authorisation.
Find your limit before production does
Half an hour with an auditor to define load objectives and scope the test.
Phone: +34 686 250 244 (Mon-Fri, 9:00 to 18:00 CET) · Email: info@jaymonsecurity.com
We reply within 2 working hours.
