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.

Planned downtime doesn't alert#

A project in maintenance mode is recorded as Maintenance, not down, and raises no alerts while it's on. Its 503 is intended, and an alert about downtime someone chose teaches people to ignore the ones that matter.

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.