How to set up checks that catch a broken API before your customers or integrations do.
Direct answer: To monitor an API endpoint, run a scheduled HTTP check against the endpoint URL and verify both the response status code and response time, then route alerts to whoever owns that service. Critical endpoints – billing webhooks, core data access – should be checked more frequently and alert faster than secondary ones.
Key takeaways
- Status code and response time are the two things a check confirms – there’s no request/response content inspection.
- Not every endpoint needs the same check frequency; prioritise by what depends on it.
- Endpoints that require authentication can’t be checked directly, since monitors can’t send credentials or custom headers – monitor a public health endpoint instead, or the anonymous-accessible parts of the API.
- Alerts should identify which endpoint failed and how – not just “API down.”
What does it mean to monitor an API endpoint?
API endpoint monitoring means running an automated, scheduled request against a specific route and checking that it returns the expected status code within an acceptable response time. It’s more targeted than monitoring “the API” as a whole, because individual endpoints can break independently of each other and of general uptime.
Which endpoints should be monitored?
Start with endpoints where a failure has direct customer or business impact:
- Billing and payments – checkout, subscription status, webhook receivers.
- Core data access – whatever publicly reachable endpoint your product can’t function without.
- Public health or status endpoints – a dedicated route that reflects the health of internal, authenticated services without requiring a monitor to authenticate itself.
Secondary or internal-only endpoints can be monitored at lower priority, or added once the core set is stable.
What should a check actually verify?
A useful API check confirms:
- Status code – the expected success code (usually 200 or 201), not just “any response.”
- Response time – against a threshold that reflects acceptable performance for that endpoint.
Illustrative example using anonymised data.
Sentinel performs ongoing HTTP checks to confirm services are up, responding with the expected status code, and within expected response-time thresholds. It does not inspect request or response content – there’s no way to send custom headers, credentials or a request body, and no way to validate the body of the response. A “successful” 200 response that’s actually empty or malformed won’t be caught unless the endpoint itself is designed to return a non-200 status when something is wrong internally.
How do you monitor endpoints that require authentication?
You can’t monitor an authenticated endpoint directly, because Sentinel’s checks can’t send a token, session cookie or any custom header with the request – only an anonymous request to the URL. Two practical options:
- Monitor a dedicated public health or status endpoint that your application exposes specifically so it can report on the state of authenticated services without requiring the monitor itself to authenticate.
- Monitor the authenticated endpoint’s anonymous behaviour where that’s meaningful – for example, confirming a login endpoint consistently returns the expected status for an unauthenticated request, which at least confirms the route is reachable and responding, even though it can’t confirm a real login succeeds end-to-end.
Neither substitutes for real transaction testing. If end-to-end authenticated-flow monitoring matters to your business, that currently sits outside what Sentinel checks.
How often should an endpoint be checked?
Match frequency to blast radius. Billing and other revenue-critical endpoints – where a failure is immediately expensive – are worth checking every one to five minutes. Lower-impact internal endpoints can run on a longer interval without meaningfully increasing risk.
Example: a small SaaS API monitoring set
| Endpoint | Check | Priority |
|---|---|---|
| /health (public status endpoint) | Status 200 + response time | Critical |
| /billing/webhook | Status 200 | Critical |
| /api/v1/status (public) | Status 200 + response time | High |
| /api/v1/docs | Status 200 | Medium |
Frequently asked questions
Can I monitor an endpoint that requires authentication?
Not directly – Sentinel’s checks can’t send a token, credential or custom header with a request. Monitor a public health endpoint instead, or the anonymous-accessible response of the route where that’s still a meaningful signal.
Is checking the status code enough on its own?
It’s what Sentinel checks, alongside response time – there’s no content or field-level validation available. A 200 response with a broken or empty body won’t be caught unless the endpoint itself is built to return a non-200 status in that case.
How is this different from monitoring general application uptime?
General uptime monitoring confirms the app or site loads. Endpoint monitoring targets specific API routes that can fail independently, even while the rest of the application is fine.
Get started
API endpoint monitoring is one piece of the wider approach covered in the SaaS monitoring guide for small teams. Sentinel’s Team plan covers up to 100 monitors, enough for a full endpoint set alongside application, SSL, DNS and domain checks.