Glossary
Probe
A monitoring probe is one scheduled attempt to use a service from outside it, ending in a single pass or fail verdict.
Also called Check, Monitoring check, Status probe.
A monitoring probe, also called a check or a status probe, is a single test: the monitoring system tries to use your service the way a client would and records what happened. For a website that is an HTTP request. For a database port it is a TCP connection. For a certificate it is reading the expiry date from the TLS handshake. Each probe ends in a verdict, usually with a response time and enough detail to explain the verdict afterwards.
Probing from outside is the point. Anything running inside your infrastructure shares its fate. It cannot tell you that your DNS is broken, your certificate has expired or your load balancer is refusing connections, because its own traffic never went through any of them. An outside probe is deliberately naive, and that naivety is what makes its verdict trustworthy.
It also brings the central problem of monitoring: a probe measures the path as well as the destination. When a probe fails, something between the prober and your service failed, and the prober's own network is part of that something. Retrying, requiring several failures in a row, asking a second location and checking the prober's own connectivity all exist to answer one question: was the failure on your side or on mine?
The word has a second meaning in Kubernetes. Liveness, readiness and startup probes are checks the cluster runs against its own containers. A failed liveness probe restarts the container, a failed readiness probe stops traffic being sent to it, and a startup probe holds the other two back until the app has started. They run inside the cluster, so they complement an outside monitoring probe rather than replace it.
| Probe | What it does | Fails when |
|---|---|---|
| HTTP | Requests a URL and reads the status code, and sometimes the body. | The request times out, the connection fails, or the status or content is not what was expected. |
| TCP port | Opens a connection to a host on a given port. | The connection is refused or does not complete in time. |
| ICMP ping | Sends an echo request and waits for the reply. | No reply arrives in time. Some firewalls block ICMP, so a failure can mean a filtered network rather than a down host. |
| DNS | Looks up a name and compares the answer with what is expected. | The lookup fails, times out, or returns the wrong records. |
| SSL certificate | Reads the certificate the server presents during the TLS handshake. | The certificate has expired, is about to, or does not match the host name. |
| Kubernetes liveness or readiness | The cluster checks its own container by an HTTP request, a TCP connection or a command run inside it. | A liveness failure restarts the container. A readiness failure stops traffic being sent to it. |
Questions
What is a status probe?
Another name for a monitoring probe: one scheduled check of whether a service is up. The name is common where the result feeds a status page or a health dashboard. A status probe usually requests a known URL or health endpoint and reports whether the answer came back in time and with the expected status.
What is the difference between a probe and a check?
Usually none. Most monitoring tools use the two words for the same thing: one attempt to reach a service and judge the result. Where a difference is drawn, the check is the configuration, meaning what to test, how often and what counts as a pass, and a probe is one run of it, or the agent that performs the runs.
What does a monitoring probe record?
At least a verdict, pass or fail, and the time it ran. Most also record how long the attempt took and the detail behind the verdict: the status code returned, the error message, the address the name resolved to or the certificate's expiry date. That detail is what lets someone explain a failure afterwards instead of guessing.
Why do monitoring probes give false alarms?
Because a probe tests the whole path, not just your service. A congested network, a faulty DNS resolver or a routing problem near the prober looks the same as an outage from where the probe sits. The usual defenses are retrying before trusting a failure, requiring several failures in a row, and confirming from a second network before alerting.
Where does Uptimely run its probes from?
From one vantage today: one server on one network. To keep a single location honest, a result that would make a monitor's status worse is re-checked once before it counts, a check taken while Uptimely's own network was degraded is discarded rather than counted, and an incident needs 2 failed checks in a row by default.
In Uptimely
Uptimely probes from one vantage today. Checks run as often as every minute; a website or API check passes only on a status from 200 to 399, and it times out after 30 seconds by default, adjustable from 1 to 60. A result that would make a monitor's status worse is re-checked once before it counts, and an incident or alert is declared only after 2 consecutive failed checks by default, which you can set from 1 to 10. A check Uptimely cannot judge honestly, because its own network was degraded at that moment, is discarded and left as a gap in the history rather than counted as an outage. The Ping monitor opens a TCP connection to port 80 rather than sending ICMP.
Uptimely probes websites, APIs, ports, DNS and certificates as often as every minute on every plan, and re-checks a result that would make a status worse before it counts.
Start monitoring free →Read next
Part of the Uptimely monitoring glossary — plain definitions of the vocabulary uptime monitoring, incident response and status pages are discussed in. Something here read wrong to you? Email support@getuptimely.com.