Skip to main content
An outside-in check runs from Observer’s own probe locations, outside your network. It sees your public endpoints the way your customers do, and it needs no Observer Agent. Use it for public websites, APIs, DNS records and certificates. For anything private, use an agent inside your network.
Outside-in checks are rolling out. Probe locations are being enabled one at a time, and the console shows only the locations that are available to you.

​
What can run

Ping (icmp) checks are not available yet. No location offers ping, so the form does not show the Ping type and a ping check cannot be saved. Use a TCP or HTTP check for the host instead. The configuration of each type is the same as on an agent. See Probe types. Thresholds use strict operators, as everywhere in Observer. A target that cannot be reached reports no data, and an outside-in check treats no data as unhealthy by default.

​
Create a check

1

Open outside-in checks

In the console, open Metrics and select Outside-in checks, then create a check.
2

Set the target

Choose the type and enter the URL, host or domain. The form refuses a target that outside-in checks cannot reach (see Blocked targets) as you type.
3

Choose locations and interval

Pick one or more locations (up to 8) and how often the check runs, from your plan’s minimum up to every 60 minutes. Pick two or more locations so an outage can be confirmed: with one location, a failure reads Degraded at most (see How the status is decided).
4

Save

The check starts within seconds. Its page shows the overall status and each location’s latest result. Add the check to a status page like any other metric.

​
Locations

Probe locations run in Europe, the United Kingdom and the United States. The console labels each location as “City, CC”, a city and a two letter country code, for example Frankfurt, DE, London, GB and Ashburn, US. Each check lists the locations it runs from. Per-location results are shown on the check’s page and kept as evidence for incidents (see Incident evidence).

​
How the status is decided

Every location evaluates the check itself, with strict operators, and reports its own result. The check’s status has two levels of failure:
  • A failure seen from one location reads Degraded.
  • A failure seen from two or more locations reads Unhealthy.
  • With no location failing, the check reads Degraded if any location reports a degraded result (for example a response time between the thresholds), and Healthy otherwise.
A check watched from a single location can at most read Degraded, since a second location is never there to confirm the failure. The same applies while only one of its locations is reporting. Details:
  • Only fresh results count: a location’s latest result must be no older than twice the check’s interval plus 60 seconds, measured from the newest result. A location that stops reporting is not counted until it reports again.
  • A location that cannot reach the target reports no data. With the default treatment of no data as unhealthy, that counts as a failure. If you set the check to treat no data as degraded or healthy, it counts as that level instead.
The check’s page shows each location’s latest result and a Verdict row that applies this rule to them, for example “1 of 3 locations failing: degraded until a second location confirms”. Per-location results also appear in incident evidence. The overall result is written once per interval or when the status changes. It then follows the same dwell, incident, SLO and notification rules as any other metric.

​
Blocked targets

Outside-in checks run on Observer’s infrastructure, so they only reach public internet addresses. The check is refused when its target, or any address its hostname resolves to, is:
  • private or internal: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 100.64.0.0/10, IPv6 unique local fc00::/7;
  • loopback, link local or unspecified: 127.0.0.0/8, 169.254.0.0/16, 0.0.0.0/8, ::1, fe80::/10, ::;
  • a cloud metadata service address, such as 169.254.169.254;
  • multicast, broadcast, reserved, or a documentation or benchmarking range;
  • an IPv6 address that embeds an IPv4 address (mapped, NAT64, 6to4, Teredo), or anything outside global unicast 2000::/3;
  • a single label name, or a name under an internal suffix such as localhost, local, internal, lan, home, corp, home.arpa, cluster.local, svc, test, invalid, onion, localdomain, intranet or private.
Hostnames are resolved through public DNS, and every address in the answer is checked, on every run. Each redirect is checked again before it is followed. Other limits:
  • No secret references. Fields that name an environment variable on the probing host (header_refs, client_cert_ref, client_key_ref, ca_cert_ref) are refused, so mTLS and secret headers need an agent.
  • Requests time out after at most 10 seconds.
  • HTTP checks follow at most 5 redirects and read at most 1 MiB of the response body.
  • Connection and proxy headers cannot be set: Host, Connection, Content-Length, Transfer-Encoding, Upgrade, TE, Trailer, Keep-Alive, Expect, Forwarded, X-Forwarded-For, X-Forwarded-Host, X-Real-IP, and any Proxy- header.
  • A DNS check that names its own resolver must use a public IP address on port 53.

​
Plan limits

Outside-in checks also count toward your plan’s metric limit.

​
After a downgrade

When you move to a plan with fewer outside-in checks, the checks over the new limit are paused, newest first, after the same grace period as other plan limits. You can choose which checks stay active in Billing. Paused checks are never deleted: they keep their history, are not run from any location, and cannot be edited while paused. Upgrading resumes them, oldest first. Checks that run more often than the new plan’s shortest interval run at that minimum until you upgrade. Their configured interval is kept and comes back when you upgrade.

​
Identify the requests

HTTP requests from outside-in checks send this User-Agent, unless the check sets its own User-Agent header:
The link points to this page. Use the header to recognize the checks in your logs or to allow them through a firewall rule.