Site health

Uptime monitoring built into analytics: outages, degraded sites and silent collectors detected within minutes, flagged on the chart and named as the cause of the drop.

The most common reason traffic falls off a cliff is that the site stopped answering. A tracking snippet cannot see that: a page that returns an error never runs it, so from the dashboard's side an outage and a quiet afternoon look the same. Numative watches the site itself as well as its traffic, and when the two disagree it says so.

What is watched

Availability. Every ten minutes Numative fetches your homepage and up to two of your busiest pages. A 5xx, a 429, a timeout, a DNS or TLS failure, or a refused connection is a failing look. A challenge page or a login wall is not: that is about Numative's access, not your visitors'.
Collection. Once an hour, Numative checks that pageviews are still arriving from the site, bots included: any pageview proves the snippet still loads and reaches Numative. An hour that receives nothing at all, at a time of day that is never empty over the previous four weeks, is an incident, whether or not the site is up. A merely quiet hour is not; that is a traffic question, and the anomaly check answers it.
The crawler. The change-detection crawl that samples your pages a few times a day reports into the same series when it finds the homepage failing or most of what it fetched failing, and it records each failing page's status on the page itself rather than skipping it.

Incidents

Kind	Opens when	Closes when
Down	Two consecutive looks find the homepage failing. Each look retries once after a few seconds before it counts, so an outage needs four bad fetches over ten to twenty minutes.	The next look finds the homepage answering.
Degraded	Two consecutive looks find the homepage answering but taking over ten seconds, or at least half of the busiest pages failing beside it (a cached homepage in front of a dead origin looks exactly like this).	The next look finds everything answering.
Collection stopped	Not one pageview arrives for one complete hour on a busy site (50 or more an hour, usually), or for two on a quieter one (10 or more). Never opened while the site is down or degraded: that silence is already explained.	Any pageview arrives.

Sites that usually see fewer than ten pageviews an hour are not judged for collection: they have plenty of honest empty hours. Nor is an hour that has itself been empty on more than one of the last 28 days: on a site whose traffic comes in bursts, a quiet hour is ordinary. Availability is watched for every site that is not idle.

Where it shows up

A banner across every section while an incident is open, saying what was observed, since when, and what it means for the numbers on screen. It is not dismissible; it clears when the incident does. Its Check again button runs the check now rather than at the next sweep, and lets the current hour count as proof that traffic is arriving again (owners and admins; also POST /api/v1/sites/{site_id}/health).
A flag on the traffic chart, planted where the incident began. The record behind it gives the start, the end (or that it is still going), the length, and what was observed.
The cause of the drop. The daily anomaly check attaches the incident to every page that fell that day, and to the site total, ranked above every other explanation. A page's own root-cause panel does the same for any window the incident overlapped.
Email, the moment an incident is confirmed and again when it ends. On by default; the switch is on the Alerts screen.
The API: GET /api/v1/health returns the current standing, the last check, uptime over 24 hours and 30 days, the open incidents, and the incidents in a window. Incidents also appear among /api/v1/markers with kind: "incident".

Collection stopped: what it names

When traffic stops while the site answers, the incident says which of the reasons Numative can see applies:

The snippet is no longer on the homepage. The probe reads your markup on every look. A redeploy or a template change that dropped the tag is the usual cause; put it back and collection resumes on the next visit. Only said when the tag used to be in the markup and traffic stopped when it left: a snippet added at runtime (by an app bundle or a tag manager) is never in the markup, and its absence there is not a cause.
The snippet carries another site's ID. It loads fine and every hit is refused.
The snippet is there and nothing arrives. Something between the browser and Numative is stopping the requests: a Content Security Policy change, a proxy or CNAME that lapsed, or a consent manager that no longer loads the script.

Idle sites are not probed. A site that has recorded nothing for a week, or that never installed the snippet and is past its setup window, leaves the sweep, the same rule the crawler uses. An open incident keeps a site in the sweep until it closes, so the silence the idle rule reads as "parked" is never an outage nobody checked on.

What the probe sends

One request per page with the same user agent as the crawler (NumativeBot), never more than three pages per look, with one retry when the homepage fails. If your firewall challenges it, the look is recorded as a challenge rather than a failure and the site is never called down on that evidence; see blocked crawlers for how to let it through.