Monitor the availability, response time, and correctness of REST API endpoints. Cloudmon sends HTTP requests at regular intervals and validates the response status, content, and performance.
REST API monitoring in Cloudmon actively tests any HTTP or HTTPS endpoint that accepts standard REST calls. At every polling interval, Cloudmon sends a configured HTTP request to the endpoint and records whether it responded successfully, how long it took, and whether the response content matched the expected value. This lets you validate not just that an API is reachable, but that it is returning the correct data.
REST API monitors are suitable for internal microservice health checks, third-party API dependency monitoring, webhook endpoint validation, and any service that exposes an HTTP interface. Navigate to Synthetic → Web → REST API to view all configured monitors.
Navigate to Synthetic → Web → REST API and click the + button. The Add/Edit panel is organized into seven sections: Monitor Details, Request Settings, Security Details, Advanced Details, Content Checks, Configuration Details, and Alert Settings.
Monitor Details: basic identification details for this monitor.
| Field | Description |
| Probe* | The Cloudmon probe that will send requests to the API endpoint. Choose a probe with network access to the target service. |
| Display Name* | A descriptive name for this monitor, such as "Payment API Health" or "User Service Status". |
| URL* | The full URL of the API endpoint to monitor, including the protocol and any path parameters. |
Request Settings: HTTP method, headers, body, and connection settings.
| Field | Description |
| HTTP Method* | The HTTP method to use: GET, POST, PUT, PATCH, DELETE, HEAD, or OPTIONS. Use GET or HEAD for read-only health checks. Use POST, PUT, or PATCH when the endpoint requires a request body. |
| HTTP Request Headers | Key-value pairs sent with each request. Use this to pass Authorization tokens, Content-Type, API keys, or any other headers required by the endpoint. Click the + icon to add a header. |
| Request Body Type | The format of the request payload for POST, PUT, or PATCH requests, such as None, Text, or JSON. Select None for requests that do not send a body, such as GET or HEAD. |
| User Agent | An optional custom user agent string to send with the request, useful for identifying probe traffic or matching the client the API expects. |
| Accepted HTTP Status Codes | One or more HTTP status codes, separated by commas, that indicate a successful response, for example 200,201,204. If the response returns a code outside this list, the check is marked as failed. |
| Connection Timeout (seconds) | Maximum time in seconds to wait for a response before marking the check as failed. |
| Web Credentials | An optional saved credential to use for authenticating the request, instead of entering authorization details directly in the headers. |
Security Details: SSL/TLS, certificate, and protocol settings.
| Field | Description |
| SSL/TLS Protocol | The TLS protocol version to use when connecting to an HTTPS endpoint. Default is Auto, which negotiates the highest version supported by the server. |
| HTTP Protocol | The HTTP protocol version to use for the request, such as HTTP/1.1. |
| Client Certificate | Path to a client certificate file, required if the endpoint enforces mutual TLS (mTLS) authentication. |
| Certificate Password | The password protecting the client certificate file, if required. |
| Prefer IPv6 | When enabled, Cloudmon uses IPv6 addressing for the request when available. |
| Query Authoritative Name Server | When enabled, Cloudmon queries the domain's authoritative DNS server directly instead of using cached or recursive resolution. |
Advanced Details: response storage and advanced options.
| Field | Description |
| Store Response Headers | When enabled, Cloudmon saves the response headers from each check for later inspection. |
| Store Response Content | When enabled, Cloudmon saves the full response body from each check for later inspection. |
Content Checks: validate response content and structure.
| Field | Description |
| Content Type | The expected format of the response body, such as Text or JSON, used to interpret the Should Contain, Should Not Contain, and Match Regex checks correctly. |
| Should Contain | An optional string that must be present in the response body for the check to be considered successful. |
| Should Not Contain | An optional string whose presence in the response body marks the check as failed. |
| Match Regex | An optional regular expression the response body must match for the check to be considered successful. |
| Case Sensitive Check | When enabled, the string and regex checks above are matched case-sensitively. |
| Expected Response Headers | Optional headers (and optionally specific values) that must be present in the response. Click the + icon to add a header to check. |
Configuration Details: scheduling, grouping, and dependency settings.
| Field | Description |
| Interval* | The polling and reporting interval for this monitor. |
| Groups | Optional groups this monitor should belong to, making it easier to organize related monitors and apply common settings across all of them at once. |
| Depends On | An optional parent monitor this monitor depends on. If the parent is unavailable, alerts for this monitor are suppressed, reducing notification noise during related outages. |
| Tags | Optional labels for grouping and filtering this monitor. |
Alert Settings: configure alert rules and notification channels.
| Field | Description |
| Alarm Rule | Select an alarm rule to apply to this monitor, defining the metrics, thresholds, and severities that trigger an alert. |
| User Groups | The user groups that should be notified when an alarm is raised for this monitor. |
| Third Party Services | Third-party integrations (such as Slack, Teams, or ITSM tools) to notify when an alarm is raised for this monitor. User Groups and Third Party Services set here at the monitor level are automatically inherited by the attached alarm rule. |
Click Save. Cloudmon begins polling the endpoint at the configured interval immediately.
For each REST API monitor, Cloudmon tracks availability as a percentage of polling intervals in which the endpoint responded with an accepted status code, response time in milliseconds from request sent to response received, downtime duration when the endpoint was unreachable or returned an unexpected response, and the result of any configured content check.
The monitor detail page shows current status alongside availability and response time charts over the selected time window. The Outages tab records all periods during which the endpoint was unavailable or failing its content check.
Each alarm is built around a simple IF/THEN model, where you select a metric, set a threshold, and define what happens when it is breached. Alarm rule profiles for REST API monitors, covering metrics such as Availability and Response Time, are created under Settings → Configurations → Alarm Rules. Learn more.
To apply an alarm rule to a specific REST API monitor, open the monitor's Edit panel and select the desired profile from the Alarm Rule field under Alert Settings. From the same section, you can also assign the User Groups and Third Party Services that should be notified. These are inherited automatically by the attached alarm rule, so the notification routing only needs to be set once per monitor.
| Issue | What to check |
| Monitor shows as down but the endpoint is reachable in a browser | The endpoint may require specific headers such as an Authorization token or Content-Type. Check the HTTP Request Headers configuration under Request Settings, and verify the Accepted HTTP Status Codes list matches what the endpoint actually returns for this request type. |
| Content check failing but status code is correct | The response body may have changed, the Content Type setting may not match the actual response format, or the expected string may be case-sensitive. Review the current response body from the API under Content Checks and update the Should Contain, Should Not Contain, or Match Regex value to match exactly. |
| High response time but the API works normally | The probe making the request may be in a different network location than your users. High response time from the probe location may reflect a routing difference rather than an application issue. Test from a probe closer to the target service. |
| POST request returns 401 or 403 | The Authorization header or API key is missing or has expired. Update the HTTP Request Headers with a valid token, or select a saved credential from the Web Credentials field under Request Settings. Some APIs require the Content-Type header to be set to application/json for POST requests to be accepted. |