Uptime and alerts

Two different things watch your infrastructure: uptime checks watch a URL from outside, and resource alerts watch the machine from inside.

Uptime checks#

An uptime check probes a project's URL on a schedule and records whether it answered, what status code it returned, and how long it took.

Add one from the project. You give it the URL your users actually visit — the public one, over HTTPS.

It waits for repeated failures#

A check does not alert on the first failed probe. It counts consecutive failures, and alerts once there have been enough of them.

That is deliberate: one dropped packet is not an outage, and an alert that fires on every blip is one people learn to ignore. The first time you are woken at 4am by a check that recovered on its own, the alert has done you harm.

What the error field means#

When a probe fails, the recorded error is why the probe failed — connection refused, timeout, TLS failure. It is never content from your site. If you need to know what the page said, look at your logs.

Resource alerts#

Resource alerts watch the metrics the agent reports and fire when one crosses a threshold you set:

• CPU percent
• Memory percent
• Disk percent

Configure them under resource alert settings. They are off until you enable them.

Picking thresholds#

• Disk is the one that matters most. A full disk breaks things in confusing ways — a database that cannot write, logs that stop, a deploy that half completes. Set it low enough to act on, around 80%.
• CPU at 100% is not automatically a problem. A machine that is busy is a machine doing its job. Alert on sustained high CPU, not on a spike.
• Memory depends on your workload. Set it where you would want to know, not where it looks alarming.

The test for a good threshold: would you get up and do something about it? If not, it should not page you.

Where alerts go#

Both kinds deliver through notification channels. Without a channel configured, an alert is recorded but nobody is told.

What is not covered#

Uptime checks tell you a URL stopped answering. They do not tell you a page is returning the wrong thing, a background job has stopped, or a queue is backing up. For those you need checks in your own application.