Requests that fit the endpoint
Choose GET, POST, PUT, PATCH, DELETE or HEAD and add an optional body where supported. Use a purpose-built health endpoint to keep checks safe and repeatable.
A response is good.
The right response is better.
Check more than a status code. Send the request your endpoint expects, validate JSON and response headers, and see when a healthy-looking API stops doing its job.
Part of your Uptiva workspace · One workspace. Every signal.
GET /health
{
"status": "ok",
"db": { "connected": true },
"version": "1.4.0"
}All response rules passed
- Endpoint
- api.example.com/health
- HTTP response
- 200 OK
- JSON: status
- ok
- JSON: db.connected
- true
A 200 response is only meaningful when the returned data is correct. Uptiva combines accepted status codes with content, JSON and header rules so an endpoint can be checked against its actual contract.
Configure the HTTP method, headers and optional request body for a meaningful health check. Then compare response times and regional results in the same workspace used for the rest of your monitoring.
Keep this signal alongside the rest of your stack: organize related services, choose who receives alerts and follow recovery in the same workspace. The goal is a check that explains what changed and gives the right person a useful place to start.
SMALL DETAILS. USEFUL CONTEXT.More than
More than
an up or down.
Purpose-built checks.
Information you can act on.
JSON field checks
Validate fields using paths with dots and brackets. Check a health flag, dependency status or numeric value so a successful HTTP response cannot conceal an unhealthy application.
Response header rules
Require expected headers or check their values. Confirm the response format, inspect cache behavior or validate a header your service depends on.
Protected endpoints
Configure request headers or basic authentication for endpoints that require credentials. Saved sensitive header values are masked in the monitor settings.
Latency with a breakdown
Review response-time history and the DNS, connection, TLS and response phases. A slow endpoint deserves investigation even when its response rules still pass.
Failure and recovery context
Use your selected regions and alert destinations to track problems. The details card keeps response information close to the overall status and uptime history.
WHERE IT FITSMade for the work
Made for the work
you already do.
One reliable signal.
Plenty of practical uses.
Application health endpoints
Check that the application and the dependencies represented in its health response are ready. Explicit JSON rules make the definition of healthy easier to understand.
Internal product APIs
Watch authenticated endpoints that power your frontend or integrations. Keep monitoring credentials limited and choose requests that do not modify real customer data.
Deployment verification
Keep checking the response contract after a rollout. Content and header checks can identify changes that an availability-only monitor would consider successful.
FROM SETUP TO A USEFUL SIGNALStart with what
Start with what
matters most.
Use a meaningful name, choose the behavior you expect and make sure the alert reaches someone who can act. Start with one service, then add the related checks as your monitoring grows.
Open the setup guide- 01
Choose your starting point.
Choose API, enter the endpoint and select the method. Add any required headers and a request body when appropriate.
- 02
Configure the check.
Define the accepted status range and the JSON, content or response-header checks that describe a healthy answer.
- 03
Follow the signal.
Choose the interval, regions and alert destinations. Use the monitor page to compare results and investigate failed rules or slow responses.
A LITTLE MORE CONTEXTGood questions.
Good questions.
Clear answers.
The details that help you choose the right check and get a useful result.
Read the full documentationCan I validate nested JSON?+
Yes. Paths can use dots and brackets, such as data.status or items[0].ok. The response must be valid JSON, and the path needs to match the actual structure.
Which HTTP methods are supported?+
GET, POST, PUT, PATCH, DELETE and HEAD are supported. A HEAD response has no body, so content and JSON rules cannot match it.
Can I send an authorization token?+
Add the required request header in Advanced settings. Sensitive values are masked after saving. Use a token intended for monitoring with only the permissions that endpoint requires.
Can a monitor fail even with a 200 response?+
Yes. Every configured rule must pass. A wrong JSON value, missing header or rejected content can make the monitor down even when the HTTP status is accepted.
Is API monitoring the same as the Uptiva API?+
No. API monitoring checks your endpoints. The Uptiva REST API is the interface for building tools around your monitoring data and workspace.
LESS CHECKING. MORE KNOWING.One more thing
Get started One more thing
off your mind.
Bring api monitoring into your workspace.