01
Always-on platforms
SaaS products and APIs that run for weeks between deployments accumulate exactly the kind of drift soak testing exposes.
LIVE CAPACITY MODEL
Soak Testing Services
Sustained load over hours and days — the only way to find the memory leak that takes 36 hours to matter.
THRESHOLD
Direct answer / 01
What is soak testing?
Soak testing, also called endurance testing, is performance testing that applies a sustained, realistic load to a system over an extended period — typically many hours or several days — to reveal problems that only appear over time. Short performance tests pass and then the application falls over on day three. Soak testing exposes memory leaks, connection and file-handle exhaustion, unbounded log or cache growth, database bloat and gradual response-time drift, all of which are invisible in a twenty-minute load test.
What it finds
Problems that only appear over time
Memory leaks and heap growth that eventually trigger out-of-memory restarts
Database connection and file-handle exhaustion under long-running sessions
Unbounded cache, session store and log growth filling disk or memory
Gradual response-time drift as tables grow and query plans degrade
Thread and connection-pool starvation from resources never released
Scheduled jobs and batch processes colliding with live traffic
01 — Model
02 — Apply load
03 — Diagnose
Method
How soak testing is run
We apply a realistic production-level load — not a peak load — continuously for an agreed duration, typically between eight hours and several days, while monitoring memory, connections, disk, queue depth and response-time percentiles throughout.
The output is a trend, not a snapshot. A flat memory graph over 48 hours is a pass; a slow upward slope is a leak with a predictable date of failure attached.
When it matters
Who needs soak testing most
02
Systems with long sessions
Trading, healthcare and workflow tools where a user session lasts hours rather than minutes stress resource handling differently.
03
Post-incident verification
After a memory or connection incident, a soak test is the only credible way to prove the fix actually holds.
Useful answers
Questions,
clarified.
Soak testing, or endurance testing, applies sustained realistic load to a system for an extended period — hours or days — to expose memory leaks, resource exhaustion and gradual performance degradation that short tests cannot detect.
It is used to confirm a system remains stable over the duration it will actually run in production between restarts or deployments, and to catch slow-building failures before they cause an outage.
At minimum eight to twelve hours; ideally 24 to 72 hours, or long enough to cover the typical interval between production deployments. The point is to run past the horizon where leaks become visible.
Load testing measures behaviour at a target concurrency over a short window. Soak testing holds a realistic load for a long window and watches for drift, leaks and resource exhaustion.
Memory and heap trend, open connections and file handles, disk usage, queue depth, garbage-collection frequency and pause time, and response-time percentiles compared between the first and last hour.
Not on every commit — it is too slow. Teams typically schedule soak tests nightly or weekly against a staging environment, or before each major release.
Next signal
Turn uncertainty into a clear plan.
Tell us what you are building and where quality or design is slowing you down.
Start a conversation