Setup & infra probes

Not every failure starts in the UI. A flow can be perfect and still break because a service is down, a firewall is blocking a port, a hostname stopped resolving, a TLS certificate expired, or a dependency is returning 5xx. Probes are how Upliftr's agents debug those, no browser flow required.

A probe is a read-only, non-destructive check: the agents open a connection or resolve a name and close it again, they never write anything. When it fails, they map it to a concrete infra root cause, the category, the suspected cause, and the fix, the same way they root-cause a UI failure to a backend line.

The four kinds

Type	Target	Debugs
tcp	host:port (e.g. db.internal:5432)	Reachability, a firewall blocking the port, a service that's down or not listening
http	a URL	An endpoint's health (status code), an API failing outside any UI
dns	a hostname	DNS / env issues, a name that doesn't resolve (typo, missing record)
tls	host or host:port (default 443)	An expired, invalid, or mismatched certificate

Ask the agents

The fastest way is to just ask in chat, the agents pick the right probe:

Can my app reach the payments service at payments.internal:443?

Why is signup returning 500 from the API, not the UI?

Is the TLS cert on api.acme.com about to expire?

Does db.internal resolve from here?

A tcp probe to a blocked port comes back like:

✗ payments.internal:443  connection refused
  connectivity: Nothing is accepting connections on payments.internal:443. The
  service is down or not listening, or a firewall is blocking the port.
  Fix: confirm the service is running and listening on that port, and that no
  firewall or security-group rule blocks it from here.

Run one directly

Every probe is also a standalone endpoint, so a dashboard or a script can dry-run it:

curl -X POST https://app.upliftr.io/api/v1/checks/probe \
  -H "Authorization: Bearer $UPLIFTR_TOKEN" \
  -H "content-type: application/json" \
  -d '{"type":"tcp","target":"db.internal:5432"}'

{
  "type": "tcp",
  "target": "db.internal:5432",
  "status": "fail",
  "observed": "connection to db.internal:5432 timed out after 5s",
  "diagnosis": {
    "category": "connectivity",
    "suspected_cause": "The connection to db.internal:5432 timed out, which usually means a firewall is dropping packets or the host is unreachable.",
    "suggested_fix": "Check firewall / security-group rules and that the host is routable from this network."
  }
}

Read-only, and yours

Probes only ever connect or resolve, they never mutate your code, data, or infrastructure. On a self-hosted instance the agents can reach your internal services directly; on the cloud edition the same egress policy that protects every run applies, internal targets are blocked unless you allowlist them.

Where probes fit

UI flows enter through the browser; probes enter through the infrastructure. Both end in the same place, a root-caused answer. See How root cause works and Connecting server logs.