HTTP 200 is not a health certificate

HTTP 200 means a request received a successful HTTP response. It does not mean your customer found the right page, the API returned useful data or the dependency behind the endpoint is ready.

A login form can return 200. So can a maintenance page with an extremely apologetic illustration. If your check accepts the code alone, it may congratulate the illustration while the application is unavailable.

Define the response that counts as healthy

Begin with a specific endpoint and a small set of observable expectations. For a website, require content that identifies the intended page. For an API, check a meaningful value in its JSON response. Keep the condition stable enough to survive ordinary content edits and strict enough to fail when the service no longer does its job.

In RMON, create an HTTP check, choose its locations and configure the request and success conditions on Settings. Accepted status codes, body rules, response headers, timing and certificate checks answer different questions. Combine the ones your endpoint needs.

Use a read-only endpoint or a dedicated test workflow. A monitoring request runs repeatedly. An endpoint that creates a real order every minute is technically testing the checkout and practically becoming your largest customer.

Check a meaningful JSON value

Suppose a purpose-built health endpoint returns this illustrative response:

{
  "status": "ok",
  "service": "catalog"
}

Set the expected HTTP status to 200. In the body’s JSON Path rule, use $.status and the expected value "ok". The quotes matter because the expected value is a JSON string. A response containing "status": "degraded" should then fail that condition even if its HTTP code remains 200.

Leaving the expected value empty checks whether the path exists. That can be useful when the value is intentionally variable, but the presence of a field named status does not establish that its value is healthy.

The endpoint must also tell the truth. If its implementation returns “ok” without testing any dependency, RMON cannot infer the missing business logic. Choose or build a health response whose meaning your team understands.

Use headers and timing where they add evidence

A required Content-Type containing application/json can help distinguish an API response from an HTML page. RMON can validate required headers and reject forbidden ones. Header names are matched without regard to case; required values use case-insensitive containment rather than exact equality.

A response-time threshold adds a separate question: did the request finish quickly enough? In RMON, that threshold uses milliseconds, while interval and request timeout use seconds. A threshold of zero disables slow-response warnings.

Choose the threshold from the service objective and observed behavior. One universal number for a local endpoint and a remote public service makes a tidy configuration and a less tidy explanation of the alerts.

Check where redirects actually finish

The SSL policy in RMON lets an HTTP check use Default, Require HTTPS or Require HTTP. Require HTTPS evaluates the final URL after any allowed redirects. A request that starts with HTTP and follows a redirect to HTTPS can meet that policy; a final HTTP URL cannot.

With redirects disabled, the original response is final. A Location header pointing to HTTPS is not the same as following it. If you are testing the redirect response itself, use the appropriate accepted 3xx status and policy for that request.

Prove that your check can fail

A fresh green result is half the exercise. On a disposable endpoint, return the wrong JSON value, remove a required header or change the final protocol. Verify the failure reason, then restore the response and confirm recovery. Attach a test notification destination if you also want to exercise incident delivery.

Use the same response conditions when comparing locations, and inspect timestamps as well as state. A check is a repeated sample of a defined request, not a complete browser session or a guarantee about every user.

The HTTP and HTTPS guide covers the available fields and examples. Give 200 some supporting evidence. It has been carrying the entire health assessment for long enough.