ddos-sim.com All simulations Configure a test
Home › DDoS simulation testing › HTTP load test

Layer 7 · Application · http_check

HTTP load test

The http_check simulation sends bounded HTTP requests to a path you choose and records status codes and latency. It is the clearest way to rehearse a Layer 7 request flood against a domain you own and watch how the application tier responds.

Layer L7 Protocol HTTP Command http_check Access After verification

On this page

  1. What an HTTP flood does
  2. How ddos-sim.com simulates it safely
  3. What the test exercises
  4. How to run the test
  5. Availability & limits
  6. FAQ
  7. Related simulations

What an HTTP flood does

An HTTP flood (a GET or POST flood) sends far more application requests than an origin can serve, targeting endpoints that are cheap for an attacker to request but expensive for you to answer. The traffic looks like ordinary browsing, so it slips past crude network filters and exhausts worker threads, connection pools, and databases.

How ddos-sim.com simulates it safely

ddos-sim.com issues bounded HTTP requests to the exact path you specify on a single verified domain, pinned to a public address with private and loopback ranges blocked. Rate, concurrency, and worker limits are enforced per domain, and each worker refuses any target other than the one it was assigned.

Authorized targets only

Every run is bound to one verified domain you have proven you own. Ownership is checked over DNS or HTTPS before anything is scheduled, and running traffic against systems you do not own or are not clearly authorized to test may be unlawful. See the Acceptable Use Policy.

What the test exercises

  • Application request throughput and thread/worker pools
  • Upstream, database, and cache saturation
  • Reverse-proxy and load-balancer connection handling
  • Rate limiting and caching effectiveness on hot paths
  • Error-handling and graceful-degradation behavior

How to run a http check test

  1. Verify your domain. Prove ownership over DNS or HTTPS — it is self-service and takes minutes.
  2. Add the http_check command to a timeline in the portal and set the target path or port, rate, and duration.
  3. Set health thresholds. Choose the error-rate, latency, or status-code limits at which the test should abort itself.
  4. Run and watch. Bounded workers are provisioned minutes before start and torn down the moment the last task ends, while metrics stream live.
  5. Read the results. Review the recorded latency, status codes, and worker timeline to find where your service starts to bend.

Configure a http check test in the portal →

Availability & limits

HTTP checks are available after self-service domain verification and run with prepaid credits. The free allowance covers bounded HTTPS request tests; HTTP checks fund from credit packs.

Frequently asked questions

How is this different from the HTTPS check?

The HTTP check exercises the plaintext Layer 7 path, while https_check adds a real TLS handshake per request. Use HTTP to isolate application-tier behavior and HTTPS to include TLS termination cost.

Can I target a specific endpoint?

Yes. You choose the path, so you can point the test at the exact endpoint whose resilience you want to measure, on your verified domain.

Related simulations

HTTPS resilience test https_check Run an authorized HTTPS resilience test against a domain you own. Slowloris test slowloris_check Simulate a Slowloris slow-HTTP attack against a domain you own. TCP port stress test port_check Open a controlled number of real TCP connections to a port you own and confirm how listener backlog, firewalls, and connection tracking hold up under load.

Rehearse the http check against infrastructure you own — bounded, monitored, and stopped the instant you have your answer.

Configure a test
← All DDoS simulations
© 2026 ddos-sim.com · Authorized testing only. Simulations · Terms · Acceptable use · Privacy