HTTP 200 is a starting point
An API can return HTTP 200 while its response describes a degraded service. A reverse proxy can also answer successfully while a downstream operation fails. API monitoring becomes more useful when the check expresses the contract of one endpoint rather than treating every successful response as proof that the whole application works.
MetriBeacon's HTTP monitors support expected status codes and, for GET requests, response text or a top-level JSON field. Start with a small health endpoint that you own and understand. Keep the response free of customer data and secrets.
Decide what your endpoint should prove
A shallow endpoint might confirm that an application process can answer. A deeper endpoint might also check a required dependency. Both can be useful, but they answer different questions. Avoid building an expensive check that repeats a full transaction every minute merely to report health.
A compact response could look like this:
{"status":"ok"}
An expected HTTP 200 together with a top-level status value of ok gives the check a clear contract. Use a field the endpoint actually returns. Do not assume a nested object or an arbitrary application response matches the supported check format.
Select the right HTTP method
| Check | Method | Useful evidence |
|---|---|---|
| Expected status | GET or HEAD | The endpoint returned the expected code |
| Response text | GET | The response contains the configured text |
| Top-level JSON field | GET | A configured field matches its expected value |
HEAD does not provide a response body for a content check. If you want to verify JSON or text, use GET and review the endpoint's response. The HTTP monitor documentation describes the available configuration and supported targets.
Configure a monitor step by step
- Open the Website/API template and choose a workspace.
- Enter your own public HTTP or HTTPS endpoint with a recognisable monitor name.
- Set the expected status and a suitable check interval.
- Add a GET content check if your API contract needs one.
- Review the preview, explicitly create the monitor and wait for its first observation.
- Inspect both a normal result and a controlled failure before relying on alerts.
The checker supports public targets on ports 80 and 443. It cannot reach localhost or your private network. For a private API, collect evidence inside that network and send suitable measurements or events through the HTTPS API.
Protect authentication details
When a supported check needs a credential, use the configured secret-header mechanism. Do not put a token into a query string, a public example or the health response. Limit the credential to the purpose and access the check actually needs.
Review redirects as part of endpoint design. A check that follows a redirect to a login page may be observing the wrong resource. Secret headers are not forwarded to a different origin. Prefer a stable health URL whose response you can inspect directly.
Read failures and unknown results separately
An unexpected status or failed content match is a negative observation for the configured contract. An unknown result or a quota pause is different: monitoring does not have the same evidence about your endpoint at that point.
Compare availability with coverage and the selected time window. Periodic checks sample the service; an interruption between two checks may be missed. Response time measures the monitored HTTP request, not the full time a browser needs to load and render your application.
The website monitoring guide covers these distinctions. Add a confirmed email or Telegram destination, test delivery and select an alert appropriate to the endpoint's importance.
Frequently asked questions
Can a JSON check verify every API operation?
No. It evaluates the configured response and field. Use separate meaningful endpoints or observations for operations that have different failure modes.
Can I monitor a private endpoint directly?
The public checker cannot access a private address. Use a local collector and the ingest API for internal observations, with appropriate credentials.
Should I always choose the shortest interval?
Choose an interval according to detection needs and the endpoint's cost. More frequent requests also create more load and consume available monitoring budgets. Verify your account's current limits.
Start with one explicit contract
Use the Website/API template below for one endpoint, document what its result means and test a known failure. Add more checks when each provides distinct evidence rather than another copy of the same status code.
