Ramp-Up vs Ramp-Down API Load Test Template

What goes up should come back down

Most tests stop at the peak. The ramp down is where a different class of bug lives: connection pools that never release, caches that stay bloated, autoscalers that flap, queues that keep draining long after traffic left. This template ramps up in steps, holds, then ramps down the same way, and compares the two halves: at the same user count, is response time the same on the way down as on the way up?

Configuration

Run this templateOpens the cloud test form with these values filled in. Free plan runs it at the free user limit; sign in or create a free account first.

The button prefills users, duration and the six-step ramp-up. The cloud test form ramps down at the end of the duration; to control the ramp-down shape step by step, use the k6 script below, which mirrors the stages.

What to read in the results

• Response time at equal user counts, both directions. Use the Timeline tab and compare the minute at 300 users going up with the minute at 300 users going down. Higher on the way down means something did not release: pools, memory, a backlog.
• Throughput on the way down. It should fall in step with users. If requests per second stay high after users drop, a queue is draining; if it drops faster than users, the server is still recovering from the peak.
• Errors after the peak. Errors that appear only during the ramp-down are scale-down events killing pods with requests in flight, or connections closed by a pool that shrank too aggressively.

Pass/fail thresholds for this template

Set them on the test; a run that passes on the way up and fails on the way down is the finding this template exists for.

The same scenario as a k6 script

As a k6 script the stages are symmetric, so the two halves line up minute for minute.

import http from 'k6/http';
import { check, sleep } from 'k6';

const up = [], down = [];
for (let i = 1; i <= 6; i++) up.push({ duration: '50s', target: i * 100 });
for (let i = 5; i >= 0; i--) down.push({ duration: '50s', target: i * 100 });

export const options = {
  stages: [...up, { duration: '5m', target: 600 }, ...down],
  thresholds: { http_req_duration: ['p(95)<500'], http_req_failed: ['rate<0.005'] },
};

const BASE = 'https://api.example.com';

export default function () {
  check(http.get(`${BASE}/items?limit=20`), { 'items 200': (r) => r.status === 200 });
  check(http.get(`${BASE}/items/7/recommendations`), { 'recs 200': (r) => r.status === 200 }); // calls a downstream service
  sleep(1);
}

When to run it

• After changing pool sizing or keep-alive settings on the API or its downstreams.
• After enabling autoscaling to see scale-down behaviour, not just scale-up.
• When p95 after an incident stays high this reproduces the recovery.

FAQ on ramp-up versus ramp-down testing

Why would response time be worse on the way down?

Because the peak left something behind: a bloated cache, a pool that grew and now contends, a queue that is still draining, or an autoscaler removing capacity faster than load falls. The ramp-down turns that into a number.

The cloud test form has no ramp-down steps. How do I get them?

The form ramps down at the end of the duration. For a stepped ramp-down that mirrors the ramp-up, use the k6 script above; the results page reads it the same way.

Should the hold be longer?

Long enough for whatever grows during the peak to grow: five minutes exposes pools and queues, thirty exposes memory. Start with five.

Is this the same as a soak test?

No. A soak holds one level for hours to find leaks. This compares the two slopes around a short peak to find what does not release.