What counts as a successful run?

A 2xx, and only a 2xx. Anything else, a 4xx, a 5xx, a timeout, a connection error, is a miss.

Does it follow redirects?

No. A 3xx means the endpoint moved, and a trigger that follows it isn't doing the work you asked for, so a redirect is a miss.

Which methods can it send?

Write methods: POST by default, plus PUT, PATCH and DELETE. Read-only methods aren't offered, because a trigger has to act.

How do I stop anyone else calling my endpoint?

Require a secret in a request header, set that header on the scheduler, and reject calls without it. Request headers are stored encrypted.

How is this different from a heartbeat?

It's the inverse. A scheduler calls your URL on the interval; a heartbeat waits for your job to call ours. Use a scheduler when the work has an endpoint, a heartbeat when the job has no address to call.

Scheduler monitoring

Know the moment a scheduled task misses its window.

Get Started Free Read the docs

UptimeX runs the job and grades the answer.

A scheduler is the inverse of a heartbeat: UptimeX calls your URL on the interval. It's cron as a service, with the alerting already attached.
Point it at an endpoint that does work when called, a cleanup route, a report generator, a queue drain, a cache warmer, and you've replaced the crontab you were going to write, plus the monitoring you were going to forget to put on it.
Success is a 2xx, and only a 2xx. Redirects aren't followed: a 3xx means the endpoint moved, and a trigger that lands somewhere else did not do the work you asked for, so it counts as a miss.
There's no fail-streak debounce either. On a health check, one blip that fixes itself is noise worth swallowing. On a trigger, a run that didn't happen is a run that didn't happen, and each result stands on its own.
POST is the default and read-only methods aren't offered, because a trigger has to act. Auth headers and a request body are both supported.
That last part matters more than it sounds: your endpoint is now callable on a schedule by anything that learns the URL. Require a secret header, set it on the scheduler, and reject calls without it.

Point it at something that does work

The endpoint is yours, the cadence is the interval, and the verdict is whatever status you return.

curl -X POST https://api.uptimex.co/v1/monitors \
-H "Authorization: Bearer upk_your_key" \
-H "Content-Type: application/json" \
-d '{
  "type": "scheduler",
  "name": "Hourly rollup",
  "url": "https://example.com/cron/rollup",
  "interval_sec": 3600
}'

Everything around the check.

Tune it when the defaults aren't right.

Interval, slow threshold, timeout, failure streak, redirects, SSL and domain expiry. Every knob the create form has, with a sane default on each.

Read the docs

Alerts on the change, not every minute.

Once when it breaks, once when it recovers, to Slack, Discord, a webhook, email, or your phone. A confirmation streak holds back the blips.

Explore notifications

A status page your users can read.

Every monitor can back a public status page with ninety days of history, on your own domain, so the question answers itself.

Explore status pages

Every outage, written down as it happens.

A confirmed failure opens an incident and keeps the timeline, detected to resolved. The first half of the post-mortem writes itself.

Explore incidents

Planned downtime that pages no one.

Schedule a window and the monitors it covers stop being checked, so nothing alerts, no incident opens, and the time is left out of your uptime.

Explore maintenance

Everything else you can watch.

HTTP / Website, Keyword, API, Heartbeat, DNS, and Port. Every one reports up, slow, or down, on the same interval, into the same alerts.

All check types