Check types
All seven live check types and when to reach for each.
Seven check types are live, and picking one comes down to a single question: what signal do you need? Is my page up, is my API returning the right data, is my cron job still running, is my infrastructure reachable, is my DNS what I published?
| Type | Direction | Success means |
|---|---|---|
| HTTP | Outbound | The URL responds with an acceptable status. |
| Keyword | Outbound | The response body contains (or omits) the text you named. |
| API | Outbound | A JSON field in the response has the value you expect. |
| Heartbeat | Inbound | Your job checked in on time. |
| Scheduler | Outbound | Your endpoint ran when we called it. |
| Port | Outbound | The TCP port accepted a connection. |
| DNS | Outbound | The record resolves, optionally to the value you expect. |
HTTP, Keyword, Heartbeat, and Port are included on the free plan; API, DNS, and Scheduler require a paid plan.
#The HTTP family: HTTP, Keyword, API
These three share one engine: an HTTP request on your interval, judged by rules. They differ only in what does the judging:
- HTTP judges the status code: any 2xx or 3xx by default, or an exact expected status you set.
- Keyword adds text rules: the body must contain, or must not contain, the strings you set. A 200 that renders an error page still fails.
- API adds JSON field rules, like
status: ok, so you watch a health endpoint's real signal instead of its status code. A paid type.
All three default to a HEAD request and switch to GET automatically when content rules need the body. Request headers (for auth) and request bodies (for write methods) are available on every one; see Create a monitor for the full field list.
#Heartbeat
Everything else here reaches out to your systems; a heartbeat waits for your system to reach in. Each heartbeat monitor gets a ping URL, and your cron job, worker, or backup script calls it (a plain GET or POST, no auth) at the end of every run:
curl https://upcheck-api-a.rekwiem.com/v1/heartbeats/<id>/pingYou declare the expected gap between pings, plus a grace buffer (60 seconds by default) for jobs that run a little long. If the gap passes with no ping, the monitor goes down: silence is the failure signal. Use it for anything that should happen on a schedule but has no URL to probe.
#Scheduler
A scheduler is the inverse of a heartbeat: UpCheck calls your URL on the interval, so it is cron as a service, with alerting built in. Point it at an endpoint that does work when called, a cleanup route, a report generator, a queue drain.
Because it is a trigger and not a health check, the rules are stricter:
- Success is a 2xx, and only a 2xx. Redirects are not followed; a 3xx means the endpoint moved, which is a miss.
- Each run's result is the status. There is no fail-streak debounce: a failed trigger is immediately worth knowing about.
POSTis the default method, and read-only methods are excluded, a trigger must act. Auth headers and a request body are supported.
#Port
A port monitor opens a TCP connection to a host and port on your interval. No HTTP, no rules: success is "the port accepted", and latency is recorded. The host can be a hostname or a public IP address. Use it for databases, mail servers, game servers, anything that listens on a port but does not speak HTTP.
#DNS
A DNS monitor resolves a record on your interval and fails when resolution fails. Record types: A, AAAA, CNAME, MX, TXT, and NS. Optionally set an expected value, and the check also fails when the answer does not contain it, which catches hijacked or fat-fingered records, not just missing ones. The target must be a hostname; resolving an IP literal is refused.
Ping and UDP