HTTP Request — Send Exactly the Request You Mean
This sends an HTTP request you specify completely — method, headers, authentication, body — and shows the entire response without a browser in the way. Control over the exact request is the point: a browser adds headers, follows redirects, applies caching and negotiates content on your behalf, and every one of those can be the thing you are trying to investigate.
Why run it
For an operator, the most common use is proving what an origin does independently of what a CDN or load balancer does in front of it. Requesting the origin directly with the same headers the edge would send separates "the application is broken" from "the edge is serving something stale or transforming the response". It is also how you test behaviour that only triggers under specific conditions — a particular Host header, an authentication scheme, a content type the browser will never send on its own.
Why automate it
Endpoints that are rarely exercised are the ones that break unnoticed: a health endpoint a load balancer depends on, a webhook receiver, an internal API called by one nightly job. Nothing touches them between failures, so the failure is discovered by the job that needed them. Scheduling a request that asserts on status and content turns that into a check with a known-good baseline, and validating the response body rather than just the status catches the case where a 200 is returned with an error document.
What it gives you
Precise, repeatable control over what gets sent, which is what lets you isolate a layer instead of testing the whole stack at once. Scheduled, it puts a monitor on the endpoints nobody exercises until they matter.