Uptime monitoring

Setting up a monitor

A monitor is a URL Provisore requests on a schedule from its own infrastructure, not from your server, so it catches a server that is up while Nginx or the application is not. Add one on the Uptime page in the sidebar, or under Uptime checks on a site's Logs page. Adding or editing a monitor needs the Pro plan or above.

• Check. An HTTP request, a WebSocket handshake, or a TCP connection. See below for what each one proves.
• Method. GET or HEAD, for an HTTP check.
• Expected status. A range, so an endpoint that returns 204 or 301 can be monitored as it is.
• Interval. From 1 minute to 1 day.
• Timeout. Up to 30 seconds.
• Redirects. Followed or not.
• Thresholds. How many consecutive failures confirm an outage, and how many consecutive successes confirm a recovery. Between 1 and 10 each.

Attach a monitor to a site and the site's pages show whether it is up.

What each kind of check proves

• HTTP request. Fetches the URL and checks the status. It is the only kind that can tell a working site from a domain this server has no configuration for, because the Host header is what separates two sites on one machine.
• WebSocket handshake. Performs the real opening handshake and requires 101 Switching Protocols with a Sec-WebSocket-Accept derived from the key Provisore generated. Provisore verifies that header, so a pass means Nginx proxied the upgrade and your application answered in the protocol. Use it for a proxied WebSocket endpoint. A plain HTTP request to one only ever gets an error status, and widening the status range to accept that proves less.
• TCP connection. Opens a connection to a host and port, then closes it. A pass proves the port accepts connections. It does not prove the right service is behind it, or that any particular site is configured, because a TCP handshake carries no hostname. Use it for services that do not speak HTTP, such as a database, a game server, or an SMTP relay, and keep an HTTP or WebSocket check for anything that serves the web.

The monitor a site gets automatically

A new site has Monitor uptime switched on. Its first successful deploy then creates a monitor that fetches the site's health check path over HTTPS, or / when it has none. What that check accepts depends on the kind of site.

• A site that deploys code. 200 to 399. The URL is your application's own, so any other status is a problem.
• A reverse proxy or a served directory. 200 to 499, unless you name a health check path. At / both can answer 404 legitimately: a directory with no index file, an app that routes elsewhere, a WebSocket port handed a plain GET. Nginx answers 502 or 504 when it cannot reach the port behind a proxy, and that is the failure this check catches.

A check that accepts 404 cannot tell a working domain from one this server no longer serves, because an unconfigured hostname answers 404 too. A health check path that must exist removes the doubt and moves the check to 200 to 399. Where a check still cannot tell the two apart, the monitor's card says so.

Status and history

Status changes only when a monitor crosses its thresholds, so a single failed request does not register as an outage. pending means no check has finished yet. Changing what a monitor checks, or disabling it, returns it to pending and clears the counters.

Check history is kept for 30 days and shown over 1-hour, 24-hour, 7-day, and 30-day windows with an uptime percentage. A check that could not be attempted is recorded as skipped and left out of the percentage.

Confirmed changes send monitor.down and monitor.up to your notification channels.

Which URLs can be monitored

Provisore validates the target when you save it and again on every check, including each redirect, against the addresses it resolves to at that moment. It rejects private, loopback, and link-local addresses. Failure details come from a fixed set of messages and never include the response body.

Each kind takes the scheme it speaks: http:// or https:// for an HTTP check, ws:// or wss:// for a WebSocket one, and tcp://host:port for a TCP one. A TCP check must name its port. There is no sensible default, and a check pointed at the wrong port would report a healthy service that is not running.