How to Monitor an API with UptimeRobot

Last verified: September 10, 2026
By: PerfMonitoring

An HTTP 200 OK only proves that an endpoint returned an HTTP success response. It does not prove that the JSON says the service is healthy, that a dependency is connected, or that a required field exists. UptimeRobot's current API Monitoring feature addresses that gap by combining HTTP request configuration with assertions against JSON body fields, response headers, status codes, or the raw response body. [1]

This tutorial uses a read-only health endpoint and original example data. It shows how to configure authentication without exposing real credentials, add JSONPath assertions, verify a healthy response, and deliberately test a failing assertion on a temporary monitor rather than disrupting production.

What You'll Accomplish

You will:

1. decide whether you need an API monitor instead of a normal HTTP monitor;
2. configure the request method, URL, headers, authentication, and optional body;
3. create JSONPath assertions against a stable health contract;
4. combine assertions without creating brittle checks;
5. verify the healthy case;
6. verify a controlled failure case; and
7. diagnose invalid JSON, authentication, assertion, response-time, and dynamic-value failures.

Prerequisites

You need:

• an UptimeRobot account where API Monitoring is available;
• a stable API endpoint intended for monitoring or health checks;
• the expected response format;
• safe test credentials if the endpoint requires authentication; and
• permission to create a temporary clone/test monitor for failure validation.

Do not use an endpoint that creates, updates, or deletes production data as your first API monitor. Prefer a read-only GET health endpoint when one exists.

Quick Answer

In UptimeRobot, create a new API Monitoring monitor, set the endpoint and HTTP method, expand Request Details for authentication/headers/body, then add assertions for the response contract. For JSON, use JSONPath selectors such as $.health or $.dependencies.database. A monitor is healthy only when its configured assertions pass. Current documentation supports up to five assertions combined with AND or OR. Verify one healthy response, then use a temporary test monitor with a deliberately incorrect assertion to confirm failure behavior without changing the production API. [1]

Step 1: Decide Whether API Monitoring Is Necessary

Use a normal HTTP monitor when the question is simply:

Can this endpoint be reached and does it return an acceptable HTTP status?

Use API Monitoring when the question includes response meaning, for example:

Does the health endpoint report the application and database as healthy?

A service can return 200 with a body such as:

{
  "service": "checkout-api",
  "health": "degraded",
  "dependencies": {
    "database": "unavailable"
  }
}

A basic status-code monitor may call this UP. A semantic API monitor can mark it as failed because the body violates the contract.

Avoid asserting on fields that change on every request—request IDs, timestamps, random tokens, queue positions—unless the assertion checks a stable property such as “field exists” rather than an exact value.

Step 2: Create the API Monitor

Current UptimeRobot documentation describes this flow:

1. open the dashboard;
2. select New on the Monitors page;
3. choose API Monitoring;
4. enter the API endpoint URL;
5. open Request Details if authentication or payload configuration is needed;
6. configure assertions;
7. configure notifications; and
8. create the monitor. [1]

Give it a name that states the business outcome, such as:

Production checkout API — health contract

That is more useful during an incident than API Monitor 3.

Step 3: Choose the Correct HTTP Method

UptimeRobot's current API Monitoring documentation lists GET as the default and supports additional request methods for APIs that require them. [1]

For a health check, prefer GET when the API design allows it. Monitoring should be safe to repeat.

Do not use POST, PUT, PATCH, or DELETE simply because API Monitoring supports them. If a write method is truly required, design a dedicated non-destructive monitoring endpoint or test resource so repeated probes cannot modify real customer data.

This is an editorial recommendation, not an UptimeRobot product requirement.

Step 4: Configure Authentication and Headers Safely

Current UptimeRobot API Monitoring supports documented authentication methods including HTTP Basic, Digest, and Bearer token authentication, along with custom headers. [1]

For a Bearer-protected endpoint, configure the credential in UptimeRobot's authentication/request settings rather than publishing it in the URL.

If your API uses a custom header, the conceptual configuration might be:

X-Monitor-Key: <MONITORING_SECRET>

Never paste a real secret into an article screenshot or public issue.

Use a dedicated credential with the minimum permissions needed to call the health endpoint. Do not reuse a broad production administrator token for monitoring simply because it is convenient.

If credentials are rotated, include the monitor in your rotation checklist so it does not create an avoidable authentication incident.

Step 5: Use a Stable JSON Health Contract

Assume your monitoring endpoint returns:

{
  "service": "checkout-api",
  "health": "ok",
  "dependencies": {
    "database": "ok",
    "cache": "ok"
  },
  "release": "2026.09.10"
}

A useful first set of assertions would be:

$.health equals ok
$.dependencies.database equals ok
$.dependencies.cache equals ok

UptimeRobot uses JSONPath selectors for JSON body fields. Current documentation includes root fields, nested properties, array indexing, and wildcard selectors. [1]

Keep assertions tied to the operational contract. The release value above changes and is not a good exact-match health assertion unless your purpose is specifically to detect deployment-version drift.

Step 6: Combine Assertions with AND or OR

As of September 10, 2026, UptimeRobot's documentation says an API monitor can have up to five assertions and combine them with AND or OR. [1]

For the health response above, AND is the clear choice:

health = ok
AND database = ok
AND cache = ok

If any required dependency is unhealthy, the contract fails.

Use OR only when multiple different response values are genuinely acceptable. Do not use OR as a shortcut to make an unreliable check stay green.

The current assertion system also supports operators such as equals, not equals, contains, numeric greater/less-than, null/not-null, and several array/object checks. [1]

Choose the least complex operator that expresses the contract.

Step 7: Understand Invalid JSON Behavior

If you configure JSON body assertions, UptimeRobot expects the endpoint to return valid JSON. Current documentation says invalid JSON results in an incident root cause reported as Invalid JSON. [1]

This is useful because it distinguishes “field has the wrong value” from “the response could not be parsed as JSON at all.”

If this occurs, inspect:

• Content-Type and actual response body;
• reverse proxy/CDN error pages returned as HTML;
• authentication redirects to a login page;
• truncated responses; and
• server exceptions that return plain text.

Do not change the assertion to a raw-body contains check just to suppress an invalid JSON incident unless raw text is truly your API contract.

Step 8: Verify the Healthy Case

After saving the monitor, inspect its check/incident history and confirm:

• the request reaches the correct endpoint;
• authentication succeeds;
• the HTTP result is expected;
• the body is valid JSON when JSON assertions are configured;
• every required assertion passes; and
• the check response time is plausible.

Do not stop at “monitor status = UP.” Review which assertions were evaluated and whether they are testing stable fields.

If your endpoint is behind a load balancer, run enough normal checks to cover typical backend routing before declaring the configuration stable.

Step 9: Verify Failure Behavior Without Breaking Production

A monitoring system should prove that it can fail correctly.

Do not make the production database unavailable or intentionally return bad data from the real service.

Instead:

1. clone or create a temporary test API monitor;
2. point it at the same safe non-destructive endpoint;
3. change one assertion to a value that cannot be true, for example:

$.health equals deliberately-wrong-verification-value

4. route notifications to a safe test contact;
5. observe the monitor's incident behavior; and
6. delete or disable the temporary test monitor after validation.

This validates the monitoring logic rather than the resilience of your production application.

Step 10: Understand Retries and Root Cause

UptimeRobot's current general DOWN troubleshooting guide documents retry behavior for connection and application failures. Application failures—such as an HTTP status outside the success list or other application-level check failures—are retried before a DOWN state under the current documented model. [2]

When an API monitor fails, inspect the root cause before changing the endpoint. Possible classes include:

• DNS/connectivity/TLS;
• authentication;
• HTTP status;
• invalid JSON;
• JSONPath selector mismatch;
• assertion value mismatch; or
• response time.

Semantic failures are useful precisely because the server can remain reachable while the application contract is unhealthy.

Verify the Setup

The API monitor is ready when:

1. it uses a safe, repeatable endpoint;
2. credentials have only the permissions necessary for monitoring;
3. the request method, headers, and body match the documented API contract;
4. JSONPath selectors reference stable response fields;
5. the healthy response passes all required assertions;
6. a temporary controlled failure causes the expected incident; and
7. production notification routing is attached only after the logic is validated.

Common Problems and Fixes

Problem: API returns 200 but UptimeRobot marks it DOWN

Likely cause: one of the semantic assertions failed.

Fix: inspect the returned body and the failed assertion. This is expected behavior when API Monitoring is doing more than status-code checking. [1]

Problem: Incident says Invalid JSON

Likely cause: the endpoint returned HTML, text, malformed/truncated JSON, or an authentication/proxy error page.

Fix: retrieve the response independently with a safe client such as curl, inspect headers/body, and correct the endpoint or auth flow. UptimeRobot requires valid JSON when JSON-body assertions are used. [1]

Problem: Bearer authentication suddenly starts failing

Likely cause: token expiry/rotation, incorrect credential, or changed authorization policy.

Fix: use a dedicated monitoring credential and include it in your normal rotation process. Update the UptimeRobot monitor through its secure credential settings rather than putting a token into the public URL.

Problem: A JSONPath assertion works for one response but not another

Likely cause: optional fields, arrays whose ordering changes, or a response schema that is not stable.

Fix: assert on durable health fields. Use “is not null” or a structural check only when existence—not exact value—is the real requirement. Avoid $.items[0] if item order is not guaranteed.

Problem: Too many assertions make the monitor brittle

Current documentation allows up to five assertions, but five is a maximum, not a quality target. [1]

Fix: keep only conditions that should independently make the service unhealthy. Diagnostic detail belongs in application observability/logging; an uptime API monitor should remain a clear external health contract.

Problem: The endpoint is healthy but slow

Use response-time monitoring/threshold behavior separately from semantic assertions. A service can be semantically correct but too slow for users, and that may deserve a different alert severity or monitor.

Best Practices

Design a monitoring-specific health contract. Stable fields such as health, dependency state, or readiness are easier to alert on than arbitrary business payloads.

Make the request non-destructive. Repeated monitoring must not create orders, charge cards, send messages, or mutate user data.

Use least-privilege credentials. A health check usually needs far less access than an application administrator.

Do not expose secrets. Keep tokens out of URLs, screenshots, examples, and repository files.

Prefer a small number of high-value assertions. The monitor should answer “is the API healthy?” rather than reproduce your entire integration test suite.

Test failure with a clone. Changing a temporary assertion is safer than modifying the production application simply to generate an alert.

Recheck feature limits. API Monitoring is evolving; assertion limits, operators, and availability should be verified against the current help center before future edits.

When This Setup Makes Sense

Use UptimeRobot API Monitoring when a structured response must satisfy a semantic contract, especially for microservice health, external API dependencies, or readiness endpoints where HTTP status alone is insufficient.

Use a regular HTTP(S) monitor when reachability/status is enough. For a normal website, see the companion How to Set Up Website Uptime Monitoring with UptimeRobot tutorial.

For broader evaluation context, see the UptimeRobot software profile, uptime monitoring guide, uptime monitoring category, and UptimeRobot vs Pingdom comparison.

FAQ

Is an HTTP 200 response enough for API monitoring?

Not when your health definition depends on response content. UptimeRobot API Monitoring can evaluate JSON fields, headers, status codes, and raw response content in addition to basic reachability. [1]

Can UptimeRobot validate JSON response content?

Yes. Current API Monitoring supports JSONPath selectors and multiple comparison operators for JSON body assertions. [1]

How should I store API credentials for monitoring?

Use UptimeRobot's authentication/header configuration with a dedicated least-privilege credential. Do not put long-lived secrets into a public URL or publish them in documentation. Rotate the credential according to your normal security policy.

Conclusion

Good API uptime monitoring checks meaning, not just connectivity. Define a small read-only health contract, configure the correct method and authentication, assert only on stable fields, prove both the healthy and controlled-failure cases, and then connect the monitor to production notifications.

That produces a signal operators can act on without turning an uptime service into a brittle full integration-test system.

References

1. UptimeRobot Help Center — UptimeRobot API Monitoring — https://help.uptimerobot.com/en/articles/13628553-uptimerobot-api-monitoring — current page updated September 2026; accessed September 10, 2026.
2. UptimeRobot Help Center — How to Debug a Monitor Showing as Down in UptimeRobot — https://help.uptimerobot.com/en/articles/11358466-how-to-debug-a-monitor-showing-as-down-in-uptimerobot — published July 31, 2026; accessed September 10, 2026.
3. UptimeRobot Help Center — UptimeRobot Advanced Settings – Customize Your Monitor Configuration — https://help.uptimerobot.com/en/articles/11360863-uptimerobot-advanced-settings-customize-your-monitor-configuration — published February 25, 2026; accessed September 10, 2026.
4. UptimeRobot Help Center — How to Create Your First Monitor on UptimeRobot – Quick Setup Guide — https://help.uptimerobot.com/en/articles/11358364-how-to-create-your-first-monitor-on-uptimerobot-quick-setup-guide — published July 31, 2026; accessed September 10, 2026.

Editorial note: This tutorial was fact-checked against current UptimeRobot documentation. No live production API was intentionally failed and no real API secret was used to claim hands-on test results.