Help & support

Sign up, then use “Add monitor” on the dashboard. Pick a check type, enter the URL/host, set an interval, and save. Your first check runs on the next scheduled tick.

You set an interval (minimum 60 seconds) per monitor. The interval controls when a check becomes due; how quickly it actually runs depends on your plan's check cadence.

Pending just means no check has run yet. It's not an error. It clears automatically the first time a check executes for that monitor.

HTTP sends a real GET request and reads the response status code. It's checking whether your application answered correctly, not just whether the server is reachable. Ping and TCP only open a raw network connection; they never send an HTTP request, so they can't see application-level problems like a 500 error page, a WAF block, or bad content.

This is intentional, not a bug. Ping's job is “is this host reachable at all”: a connection refused (ECONNREFUSED) still proves the host answered on the network, so Ping counts that as up. TCP's job is “is this specific port accepting connections”: for TCP, that same refused connection means the port isn't open, so it's down. Same event, two different questions being asked.

HTTP only looks at the status code. A page can return 200 OK while showing an error message, an empty cart, or a broken checkout. Keyword monitoring additionally checks that the response body contains text you specify, so it catches “technically online, actually broken” pages.

It checks your certificate's expiry date on each run and warns you a configurable number of days ahead of time, so a lapsed certificate never becomes a surprise outage.

The most common cause is a firewall or bot-protection rule (Cloudflare Bot Fight Mode, a WAF, or a security plugin) blocking automated requests specifically, while allowing normal browser traffic through. Our checker identifies itself with a distinct User-Agent for exactly this reason. If your host is behind Cloudflare or a similar service, add an allowlist rule for that User-Agent (or for our check traffic generally) in your security settings.

No. Ping and HTTP check fundamentally different things, so they can disagree correctly. Ping only opens a bare network connection and never sends a User-Agent or any HTTP request, so it will never trigger an HTTP-layer bot-protection rule. If HTTP is blocked but Ping is fine, that's consistent with a firewall/WAF blocking automated HTTP requests specifically, not proof the HTTP check is wrong.

timeout: no response within the check's time budget. dns: the hostname didn't resolve. conn_refused: the target actively refused the connection on that port. unreachable: the network path itself failed (routing, firewall drop). http: the server responded, but with an error status code or too many redirects.

No. A single blip doesn't page you. An incident only opens after checks fail consecutively across a real time window, the same bar a human would use before trusting a “down” signal. This avoids noisy false alarms from a single transient network hiccup.

Yes, a recovery notification goes out the moment an incident closes, including how long it was down.

Yes, publish any monitor to get a public, read-only status page showing uptime percentage, check history, and past incidents. Nothing about your account (email, other monitors) is ever exposed on a public status page.

Yes, from the monitor's detail page. Unpublishing immediately makes the public URL return a 404.

Yes, no credit card required, and it's the full product today, not a trial.

Not yet. Every account is single-user for now. Team roles are a planned future capability.