Website and network availability monitoring

How it works

1. Sign in and add up to 5 targets you manage, using public HTTP/HTTPS addresses on standard ports 80/443, or tcp://host:port with an explicit port from 1 to 65535.
2. Choose a 5, 10, 30 or 60 minute interval. By default our server makes a GET request without reading the body; optional literal checks read a bounded response. Final HTTP 200–399 responses count as available, following up to 3 redirects.
3. Two consecutive failed checks create an outage event and in-app notification. Enable email after verifying your current account email. Continued failures do not create duplicate outage events. Recovery triggers one notification.

Manage my website monitors

Test before saving

The configuration form offers a single test without saving or sending alerts. It shows the HTTP status, rule results and available certificate expiry. A manual test also runs while paused or in maintenance. It does not change failure counts, schedules or stored history. Up to 2 tests per minute and 20 per hour per account; busy or rate-limited requests must wait. Edit a field to clear an old result, then Save to enable scheduled monitoring.

Interpreting a result

For example, with a 5 minute interval, two HTTP 503 responses trigger an alert; a later HTTP 200 triggers recovery. Scheduled intervals are best effort: network timeouts, queueing or a stopped scheduler can delay detection. This is not a multi-region service or an availability guarantee.

401/403 may indicate access controls and 429 rate limiting rather than an outage. Latency measures time to response headers, not full browser loading. Initial success does not send recovery mail.

TCP checks

For example, tcp://example.com:3389 checks whether a TCP connection can be established. It sends no application data and does not attempt authentication or read banners. TCP success does not verify RDP sign-in, database queries, TLS certificates or business health. The latency includes DNS and connection establishment. UDP is not supported. IPv6 literals must use brackets. HTTP redirects cannot change into TCP targets.

ICMP (Ping)

Use icmp://example.com or icmp://[public-IPv6], without a port. Each check sends one echo request to one validated address. Two consecutive no-reply checks trigger an alert and an echo reply triggers recovery. Filtering or packet loss may prevent replies even when the website works. The displayed duration includes DNS and process startup, not just network round-trip time. Missing programs or permissions are recorded as local checker unavailability, without outage or recovery alerts.

Certificate warnings, content rules and maintenance

HTTPS monitors can opt into independent 30/14/7-day expiry tiers for the verified leaf certificate served by the original hostname. Renewals update automatically. Invalid or expired certificates remain TLS check failures; validation is never disabled. HTTP monitors can require or forbid one case-sensitive text fragment each (up to 200 characters). These match raw response text, not JavaScript-rendered content. At most 512 KiB is read; oversized, compressed or unsupported encoded responses cannot pass content verification. No body is stored. Maintenance pauses checks and alerts for up to 7 days, then resumes automatically with a fresh baseline. Event details include first failure and last available timestamps.

Slow-response alerts

HTTP/HTTPS/TCP monitors can set a 100–15000 ms threshold; 0 disables it. Two consecutive successful checks strictly above it trigger one independent alert. A successful check at or below the threshold recovers it. Failed checks never imply speed recovery. Successful samples from the latest 50 checks show minimum, median, nearest-rank P95 and maximum. These are server-side measurements, not browser loading, ICMP RTT or an SLA.

Data and limitations

Names, complete target URLs and check results are stored on our server. Do not submit credentials, tokens or sensitive query parameters. Targets see our server's outbound IP. Checks are retained for 7 days and events for 30 days, cleaned by scheduled runs. SMTP and a scheduled task must be configured by the site operator. No page-content, sign-in or business-transaction tests are performed.