Monitors

A monitor watches one thing and keeps a status timeline for it. Checks run from Uptimely's probe runtime on a per-minute sweep; when a check result crosses the criteria you configured, the monitor changes state and can declare an incident, fire alerts, and notify subscribers — automatically.

Monitor types

The create wizard offers, among others:

• Website — HTTP(S) checks with status-code, response-time and keyword criteria.
• API — like Website, plus request options: method, headers, body and redirect behavior.
• Ping / IP — reachability checks against a host. The check opens a TCP connection to port 80 and counts a completed connection as reachable; it sends no ICMP. For any other port, use a Port monitor.
• Port — TCP connect checks against a specific port.
• DNS — query one record type and fail when the query errors or comes back empty. It checks that the record resolves, not what it resolves to.
• SSL Certificate — certificate validity and expiry.
• Domain — confirm the domain still exists, by DNS and then by WHOIS. It does not read the registration expiry date.
• External Status Page — watch a third-party provider's status page.
• Synthetic / Custom JavaScript — scripted checks.
• SNMP — poll SNMP-speaking devices.
• Incoming Request — a passive heartbeat: your job pings Uptimely, and silence beyond the expected interval is the failure signal.
• Manual — a status you set yourself, useful for composing status pages.

Request timeout

The probe request timeout is per-monitor configurable the way UptimeRobot does it: default 30 seconds, range 1–60 seconds. It's editable on Website and API monitors — in the create form ("Request Timeout (Seconds)") and later on the monitor's Request Options tab. Other monitor types use the same 30-second default, non-configurable.

Check interval and failure threshold

Each monitor runs on its own check interval, as often as every minute on every plan. A failed check, once the re-check described under flap suppression confirms it, changes the monitor's status straight away, so the status timeline and status pages stay truthful. Declaring an incident or alert waits for the monitor's failure threshold: 2 consecutive failed checks by default, configurable from 1 to 10 on the monitor's Interval page. Recovery has no threshold; the first passing check resolves what is open.

Criteria and status

Each monitor carries criteria that map check results to a status (Operational, Degraded, Offline) and decide whether an incident or alert is declared and with which severity. Criteria are edited on the monitor's Criteria tab.

Flap suppression

A result that would move a monitor to a WORSE status is confirmed by an immediate re-check before it commits — a single flaky read doesn't page anyone. Recoveries commit immediately.

Incoming-request heartbeats

Heartbeat monitors give you a unique URL; anything that can send an HTTP request can report in. If the expected interval passes without a request, the monitor degrades — the standard pattern for cron jobs and background workers.