Shared vs. private monitors, and restricted checks#

This page ties together three ideas that show up throughout the other guides: what a private monitor is versus a shared one, what makes a check restricted, and how the two interact when you’re deciding what runs where.

Private monitors: yours, on your own terms#

A private monitor is one you enrolled yourself — the agent binary running on hardware you control. It has no restrictions placed on it by Tenpm Uptime: if it can reach 10.0.0.5 or an internal admin panel, that’s the product working as intended. The blast radius of that reach is entirely your own network, so there’s nothing for the platform to guard against here.

Only checks belonging to your organisation can ever be assigned to it.

Shared monitors: ours, run on behalf of everyone#

The shared fleet is a set of monitors we operate, offered to every organisation on the platform as a way to get reach — multiple regions, a second vantage point on a public-facing check — without running your own agent. Because a single shared monitor executes requests on behalf of many different customers, it can’t extend the same trust a private monitor gets: an unvetted request from any customer’s check could otherwise be pointed at our internal network, or at an internal address of some other customer’s system that happens to be reachable from our infrastructure.

So a shared monitor independently refuses to connect to anything that looks internal — a private, loopback, link-local or carrier-grade-NAT address — no matter what a check claims about itself. Critically, this check happens against the address the target actually resolves to, re-checked after every redirect, not just the hostname you typed — so a public-looking hostname that resolves to an internal address (accidentally, or via a DNS trick) still gets refused. This is the same rule enforced independently at two points: when a check is created (so it isn’t offered to the shared fleet in the first place if it’s obviously headed nowhere useful) and again by the shared monitor itself at the moment it actually dials.

What makes a check “restricted”#

A check that can only run on your own monitors — never the shared fleet — is called restricted. There are two ways a check ends up that way:

1. Automatically, when the target is plainly only reachable from inside a private network — a literal private or loopback IP address, localhost, or a hostname ending in .local/.internal/.localdomain/ .home.arpa. There’s no point offering a shared monitor a target it could never reach, so the check form derives this for you and explains why on the check’s edit page (“restricted by its URL”).
2. By your own choice — the Never run this check on shared monitors option on the check form. This is for a target that is publicly reachable, but where the request itself carries something you’d rather a machine you don’t operate never sees: an Authorization or Cookie header, POST data with real content in it. Tenpm Uptime never inspects a check’s request for anything sensitive and decides this on your behalf — that would mean reading your headers and payloads, which is exactly the kind of thing this option exists to avoid. It’s always your call, and it defaults off.

A private-definition check (see Private-definition checks) is restricted for a third, structural reason: the server never holds its URL at all, so there is nothing to classify or hand to any monitor other than the one(s) you’ve directly loaded the definition onto. It can never be assigned a shared monitor, regardless of either setting above.

How this plays out when assigning monitors#

For a non-restricted check, which monitors actually run it is still up to you. New checks default to your own enabled monitors only, unless your organisation has turned on Automatically include new shared monitors on non-restricted checks (Organisation settings) — in which case an eligible check also starts assigned to every shared monitor, and stays current as new ones come online, until you deliberately edit that specific check’s monitor list, at which point it stops following the automatic default. See Managing monitors for where to toggle this.

One reason to assign more than one monitor to a check, shared or private: Tenpm Uptime treats a check as down only once a majority of the monitors actually assigned to it agree, so a check running on just one monitor can’t tell “the target is down” apart from “that one monitor’s own connection is having a bad day” as reliably as a check running on several can.