Availability is usually described as uptime: the process is running, the health check returns 200, the status page is green. That holds only while nothing is pushing on the service, and a DDoS test exists to find out how far the two drift apart once something is. Measured properly, availability is the share of legitimate requests a service answers correctly and in time, usually expressed as a percentage (the familiar "nines": 99.9%, 99.99%) or as an error-and-latency budget over a window.
Uptime is not the same measurement
The two definitions differ in where they stand. Uptime is measured from inside: an orchestrator probes a cheap health endpoint over a private network, and that endpoint keeps answering while real users time out at the front door. Availability is measured from outside, as good requests divided by valid requests, the way an SRE team writes a request-based service level indicator.
The budget is smaller than it sounds. 99.9% over a 30-day month allows about 43 minutes of failure; 99.99% allows about 4 minutes 20 seconds. A single 20-minute attack spends roughly half of a three-nines month and more than four months of a four-nines budget.
How an attack takes it without crashing anything
A DDoS attack does not need to crash anything to win. Pushing enough requests to inflate error rates or latency past a usable threshold is an availability failure even if every server stays up.
There are several quiet routes to it. A worker pool held open by a slowloris-style attack leaves the process alive with no thread free to serve. Latency that climbs past the client's timeout turns a successful response into a failure on the user's side. The resolver or identity provider in front of the service fails, and the service, though healthy, cannot be reached or logged into.
Dependencies compound the loss. A service that calls two others in series, each at 99.9% and failing independently, lands at about 99.8% itself, which doubles the monthly budget it burns before any attack starts. The attack only has to degrade one link in the chain.
The defence can do it too. A mitigation that blocks or challenges real users along with the flood reduces availability by up to its false-positive rate (all of it, for requests blocked outright), and those failures never appear on the attack dashboard.
What a DDoS test measures
A test measures availability the way a user experiences it: from outside the network, with synthetic legitimate clients running alongside the attack. A request counts as good only if it returns the right answer within the latency the client will actually wait, the same ground truth that yields goodput.
It reports that figure per critical path rather than one site-wide number, because a homepage served from cache can stay at 100% while login falls to zero. The result that drives decisions is the attack level at which each path drops below its target, and how much of the monthly error budget one attack of that size would spend.
Availability is the A in the confidentiality, integrity and availability triad, and it is the one property most security testing leaves out. If you are deciding which kind of test answers your question, start with DDoS Testing vs Penetration Testing.