To monitor an API endpoint for uptime and response time, schedule an HTTP request, verify the expected status, record its duration and configure separate alerts for failure and sustained slowness. Run the observer on the network path you want to test.
This walkthrough uses Warden’s HTTP monitor. You need a running Warden installation, an endpoint you control and one notification destination. Warden measures synthetic requests; it does not inspect every customer request, execute browser journeys or trace internal database calls.
1. Pick a representative endpoint
Prefer a read-only endpoint that exercises the dependencies you care about. A shallow /health route can prove the process is alive; a deeper readiness endpoint can include the database or queue. Avoid requests that create data unless the environment is designed for synthetic transactions.
2. Configure the request
Set the HTTP method, required headers, optional body, accepted status codes, redirect policy and timeout. Store the narrowest credential the check needs. Do not put secrets in a URL where proxies and logs may retain them.
For a first check, use this example and adapt it to your endpoint:
| Setting | Example | Reason |
|---|---|---|
| Type and method | HTTP, GET | A read-only request |
| Target | https://api.example.com/ready | Replace with your own readiness endpoint |
| Accepted status | 200 | A redirect or server error should not pass |
| Follow redirects | Off | Detect an unexpected redirect to login |
| Timeout | 5 seconds | Bound each attempt |
| Interval | 60 seconds | Start with a modest check rate |
| Latency threshold | 500 ms | An illustrative target, not a universal recommendation |
In Add Monitor, enter the target and interval. In Request Configuration, set the method, statuses, timeout and redirect policy. Review the latency threshold in the monitor settings. Warden checks HTTP status but does not assert that a JSON body contains a particular value; use an endpoint that returns a failing status when its dependency check fails.
3. Choose interval and confirmation
The interval bounds detection time. A 60-second interval can take nearly a minute to see the first failure. Requiring three consecutive failures reduces false alarms but adds confirmation time. Choose both together rather than copying a default blindly.
Also check the sustained-outage notification window. In Warden, opening an outage and announcing it are separate steps. The default policy can record a short outage without sending an immediate message. Read notification settings before interpreting silence as a delivery failure.
4. Track down and slow separately
Timeouts and rejected statuses are availability failures. A successful but unusually slow response is degradation. Separate incident states produce clearer notifications and better history.
5. Test the failure path
Temporarily point a non-production monitor at a controlled failing endpoint. Verify confirmation, notification, recovery and incident history. A green dashboard does not prove alerts work.
Use a disposable test service for these checks; do not stop a production API just to test the monitor:
- Return the expected status promptly: the monitor should be up.
- Return
503or stop the test service: after confirmation it should be down. - Return the expected status after a delay above the configured threshold but below the timeout: check the degraded state and notification policy.
- Restore the service and normal latency: verify recovery. Warden only announces recovery when the outage itself was announced.
The channel’s Send Test button checks delivery to the provider. The controlled failure checks the full path from evaluation to notification.
With Warden, create an HTTP monitor, open Request Configuration and set these values in the dashboard. Warden supports 10-second minimum intervals, configurable retries and timeouts, custom accepted statuses, learned P50/P95 baselines and explicit latency overrides. See the monitor guide for the current behavior.
After the first week
Review false alarms, missed incidents and the observed P50/P95 before changing thresholds. If you moved Warden to another network, the measured path changed too. If your requirement is contractual, use the API response-time SLA guide to define the denominator and reporting window separately.
Start with the quickstart, or choose Managed Warden at $49/month if you want Project Helena to operate the instance.
Product behavior: HTTP checks in v0.8.0 and notification confirmation.