Uptime monitoring

Per website the daemon probes HTTP/HTTPS (port 80/443) plus any custom TCP ports you configure per website. Mail, database and service checks (FTP, SSH, SMTP/SMTPS, IMAP/IMAPS, POP3/POP3S, MySQL, PostgreSQL, Redis, MongoDB, DNS) are set up in the service-monitoring module — each with its own port and optional credentials. Ping (ICMP) is available there too: it probes the host itself and therefore has neither a port nor credentials. Active service checks are repeated cyclically once the last check is a few minutes old. For custom endpoints with status-code, body-match, response-time and JSON-path assertions use the separate API monitoring module.

Every uptime check runs in parallel from three distributed EU monitoring nodes. A site is normally only marked “down” when at least 2 of 3 nodes report the outage — single-location ISP hiccups are eliminated as a false-alarm source. Multi-node consensus is active on every plan.

Free: 5 min, Starter: 1 min, Business: 1 min, Agency: 30 sec. Overridable per website (within the plan minimum). Planned maintenance windows suppress alerts; checks keep running during the window and count towards availability.

Instead of a single response-time number, XICTRAQ records the complete timing breakdown for every request. You instantly see whether a performance issue stems from DNS resolver, connection setup, TLS handshake or server-side processing.

Alerts as soon as the rolling P95 response time in the chosen window gets too high — even without a full outage, typical for degraded performance before a total failure. The evaluation window is selectable per website (default 15 minutes, from 5 to 180 minutes). Either with a fixed threshold (e.g. 2000 ms) or in automatic mode: XICTRAQ then learns the seasonal norm per hour-of-week (mean + deviation over the last 14 days, requiring at least 20 samples per hour-of-week) and sets the adaptive threshold to mean + 3 standard deviations. No fixed number to maintain. The cron checks every 5 minutes; configured per website under Settings.

Instead of retrying the same node multiple times after a failed check, XICTRAQ uses multi-node consensus: three nodes probe independently. Consensus is built from the latest verdict of every node seen within two check intervals, but at least the last 10 minutes. Only when at least 2 nodes report the outage AND down votes outweigh up votes does the status flip to “unreachable” and a downtime alert is opened. If only a single node reports an error (local network hiccup), the status stays green. Exception: if only one node has a counted verdict in the window, because the others are down or abstain due to a detected measurement disturbance, that verdict decides on its own. The change log entry states the node count (for example 1/1). On a tie (e.g. 1 node up, 1 down) the verdict is “flapping” — the affected node is transparently shown in the website node-consensus panel with status, response time and location.

If a site does not respond at all, XICTRAQ now distinguishes clearly: a transport-level connection failure (timeout, connection refused or blocked, HTTP status 0) is reported as “Unreachable from scan node (timeout/blocked)” with the concrete reason — instead of a misleading “Offline · HTTP 0”. The target may block datacenter IPs while still being reachable for real visitors; the node-level finding makes that transparent. Multi-node consensus decides whether this becomes an incident — if only a single node reports the error, the status stays green.

If a site answers with HTTP 403 or 503 plus a recognizable bot-protection or challenge page (e.g. Cloudflare, Imperva, Sucuri, DataDome, PerimeterX, DDoS-Guard, “Just a moment”/“Please wait”), XICTRAQ treats it as reachable — real visitors pass the challenge, the datacenter check does not. This avoids false alarms for sites behind a web application firewall.

Generated per website in weekly and monthly PDFs: uptime percentage, incident count, response-time trends and the incident list. Delivery by email or download from the archive.

One-time (date range) or recurring weekly (e.g. “every Wednesday 02:00–04:00”), per website or account-wide. Checks still run and are logged during the window, but no alerts are sent while it is active. Suppression works in three layers: a scheduled one-off window, a weekly per-website window and a weekly account-wide window.