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. Fill in the fields as follows:
| Field | Description |
| Probe | The Cloudmon probe that will send requests to the API endpoint. Choose a probe with network access to the target service. |
| 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. |
| Method | The HTTP method to use: GET, POST, PUT, PATCH, or DELETE. Use GET for read-only health checks. Use POST or PUT when the endpoint requires a request body. |
| 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. |
| Request Body | The request payload for POST, PUT, or PATCH requests. Typically JSON. Leave blank for GET requests. |
| Expected Status Code | The HTTP status code that indicates a successful response, typically 200. If the response returns a different code, the check is marked as failed. |
| Response Content Check | An optional string to match in the response body. If the string is not present in the response, the check is marked as failed even if the status code was correct. |
| Connection Timeout | Maximum time in seconds to wait for a response before marking the check as failed. |
| Monitoring Profile | The polling and reporting interval for this monitor. |
| Tags | Optional labels for grouping and filtering this monitor. |
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 the expected 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. Learn more.
To configure an alarm for a REST API monitor, navigate to Synthetic → Web → REST API → [Select Monitor] → Settings → Alarm Rule and click Add Trigger. Available metrics include Availability and Response Time.
| 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 Request Headers configuration and verify the expected status code matches what the endpoint actually returns for this request type. |
| Content check failing but status code is correct | The response body may have changed or the expected string may be case-sensitive. Review the current response body from the API and update the content check string 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 Request Headers with a valid token. Some APIs require the Content-Type header to be set to application/json for POST requests to be accepted. |