Endpoint monitors

• HTTP endpoint: expected status code, timeout, and optionally a fragment that must appear in the body.
• Database connection: the same health check the connections screen uses, now on a clock.
• TLS certificate: the monitor warns before the certificate expires, not after.

By default the check leaves our servers, over the public internet. That cannot reach an internal address — and must not: the same rule that refuses to dial a private network is what stops somebody pointing a “monitor” at a cloud metadata service.

For an address only your network can reach, have the check run from an agent installed inside it. The agent measures the status code and the elapsed time; what decides whether the service is up is still the server, against the expectations you set on the monitor. One verdict, in one place.

The screen says so while you are creating the monitor when the address is not reachable from outside, and names which of your agents could check it. Before that, the failure only showed up on the tenth consecutive check.

A single failure opens no incident — networks hiccup, and one alert per hiccup trains everybody to ignore alerts. The incident opens once failures pass the threshold you set, and closes itself when checks start passing again. The duration recorded starts at the first failure, not at the moment the incident opened.