Monitoring and metrics

Two things are watched for you without any setting up: how hard each environment is working, and whether production is answering. The first is on the environment's Metrics tab. The second is what sends an availability notification.

#The Metrics tab

Every environment has one. It shows the last 15 minutes, hour, 24 hours or 7 days — 24 hours to begin with.

#CPU, memory and disk

Each line is drawn against what the plan allows — the top of the chart is your allocation, not the machine's size. On a machine shared between environments that is the question that matters: a line near the top is this environment using what it was sold, whatever the rest of the machine is doing.

Each figure shows its peak and average over the window. Disk shows how much it has changed, because a disk that is steadily filling is the one to act on before it is full — a disk passing 80% is also a notification.

"The machine has gone quiet" under a reading means nothing has been reported for a while. That is usually a machine that is down or being rebuilt, and is worth a look at the environment's Activity.

A week is kept because a week answers the question people ask — "was it like this before the deploy on Tuesday?" For longer history, send your logs somewhere that keeps them.

#Traffic

Counted at the edge, from every request that reached the environment — so it includes requests your application never saw, such as ones the probe guard refused.

The lines are per minute over the last hour and per hour further back. The p95 is accurate to the width of the buckets it is counted in, which is plenty to tell a slow site from a fast one and not enough to benchmark a change of a few milliseconds.

Errors count 404s. A spike of them is usually a crawler or a scanner, not your site breaking. The busiest paths list is the quickest way to tell which.

Behind a CDN, this is what reached us, not what your visitors asked for. Requests the CDN answered from its cache are not in these numbers; the CDN tab shows what it served.

#Is production answering

Every running production environment is requested once a minute, at its canonical domain — your own, once you have made one canonical, and the platform hostname before that. Redirects are followed.

• Any answer below 500 counts as up. A 404 on the home page is a problem, but not an outage.
• Three failures in a row — about three minutes — and the environment is counted as down, and an availability notification is sent.
• When it answers again, a second notification says so.

The three minutes are deliberate. A single slow answer during a deploy or a restart is not something to wake anyone for, and alerting on it teaches people to ignore the alert.

Staging and development environments are not watched this way.

This check is made from one place, as an early warning that reaches whoever you chose under Notifications. It is not the measurement your uptime SLA is judged on.

#Availability for the SLA

Where a project has bought an uptime SLA, availability is measured separately, from more than one location, against your own domain — the address your visitors use — rather than against the machine. What counts is whether your site was reachable the way your visitors reach it.

Your own downtime is marked as yours. While a deploy runs, and for a few minutes after it finishes, your site is behind its maintenance page; so is it while you have switched it offline. Both are sent to the monitor as your own windows. They are recorded, but they do not count against the SLA and are not credited. Only production is measured for credits — staging and development carry no commitment.

The tiers, the figures and the credits are on Projects, and the terms that bind them are in the SLA itself. The measurements are not shown in the console today.

#What is not here

• No application monitoring of our own. Nothing inside your code is timed or traced by the platform — but you can send traces to a service you use. See below.
• No custom checks or thresholds. You cannot point the availability check at a different path, or change when it alerts.
• No per-machine charts. You see each environment against its allowance, not the machines underneath.

#Application monitoring with your own account

In the log forwarding card on the project's Configuration page, Application monitoring lets you choose an agent from your team's integrations. It needs the Admin role, and a plan that includes log forwarding.

Datadog is not offered as an agent; send to Datadog through OTLP instead.

Three things to know before relying on it:

• New Relic is for PHP. On a Node or Go application it sets variables nothing reads; use OpenTelemetry with your language's SDK there.
• The OTLP endpoint is passed as written. The same integration's endpoint is also where your logs go, and OpenTelemetry SDKs add /v1/traces to the endpoint they are given — so check where your traces actually arrive.
• It is sent when you save, to every machine the project runs on.

#Next

• Notifications — where the availability alert goes
• Logs — the detail behind a spike in errors