> ## Documentation Index
> Fetch the complete documentation index at: https://docs.use.observer/llms.txt
> Use this file to discover all available pages before exploring further.

# Outside-in checks

> Check your public endpoints from Observer's own locations, with no agent to install. A failure seen from one location reads degraded; from two or more, unhealthy.

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](/agent/overview). Use it for public websites,
APIs, DNS records and certificates. For anything private, use an agent
inside your network.

<Note>
  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.
</Note>

## What can run

| Type | What it measures | Default thresholds |
| - | - | - |
| `http` | Response time of an HTTP or HTTPS request, with optional status and body checks | Healthy under 1000 ms, unhealthy over 3000 ms |
| `tcp` | Time to open a TCP connection | Healthy under 200 ms, unhealthy over 1000 ms |
| `dns` | Resolution time of a record, from a public resolver | Healthy under 100 ms, unhealthy over 500 ms |
| `tls_cert` | Days until the certificate expires | Healthy over 30 days, unhealthy under 7 days |

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](/agent/reference/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

<Steps>
  <Step title="Open outside-in checks">
    In the console, open **Metrics** and select **Outside-in checks**, then
    create a check.
  </Step>

  <Step title="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](#blocked-targets)) as you type.
  </Step>

  <Step title="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](#how-the-status-is-decided)).
  </Step>

  <Step title="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.
  </Step>
</Steps>

## 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](/docs/guides/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

| Plan | Checks | Shortest interval |
| - | - | - |
| Free | 3 | 5 minutes |
| Starter | 10 | 1 minute |
| Pro | 25 | 1 minute |
| Business | 100 | 1 minute |
| Enterprise | Custom | 1 minute |

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:

```text theme={null}
ObserverProber/<version> (+https://docs.use.observer/docs/guides/outside-in-checks)
```

The link points to this page. Use the header to recognize the checks in
your logs or to allow them through a firewall rule.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.