# Ping/Echo

**In short:** Ping/echo checks whether a component is alive. One part sends a request and waits for a reply. If no echo arrives within a set time, the sender declares a failure.

## Explanation

Ping/echo is a way to detect faults. It is one of the fault detection tactics described in *Fault Detection Tactic*. One component sends a request to another. The receiver sends an echo back. The two messages form an asynchronous request/response pair (see *Synchronous vs. Asynchronous Communication*).

**What the echo tells you.** The echo shows that the target is alive and responding. It also shows whether the network path works and how long the round trip takes.

**The time threshold.** The sender must know how long to wait for the echo. When that time runs out with no reply, the sender declares a failure. Teams must set timeouts and failure thresholds so that short problems, such as a network delay, do not trigger needless action. Such wrong alarms are called false positives.

**Matching replies.** In the standard echo defined in RFC 792, the receiver returns the data from the request. It also returns an identifier and a sequence number. The sender uses these to match each reply to its request.

**Ping/echo versus heartbeat.** *Heartbeat* is a periodic exchange between a system monitor and the monitored process. The key difference is who starts the check. A monitor, in general, watches key components for malfunctions or network congestion.

**Shallow checks.** A simple ping shows only that the process can respond. It does not test the services the component depends on. A process that responds is not necessarily ready to serve.

**In practice.** Health endpoint monitoring uses external tools that probe an application at regular intervals. Load balancers and traffic routers use the results to send requests to healthy instances (see *Load Balancer*). Kubernetes liveness probes lead the kubelet to restart a container that fails more often than allowed. Readiness probes decide whether a Pod receives traffic.

## Example

A monitoring tool sends a small request to an order service. The service answers. The tool records the reply and moves on. Later the service stops answering. The tool waits for the configured time, then declares the service failed. A load balancer stops sending customers to that instance.

## Trade-offs

- **Probe cost.** Probes add traffic. At high frequency across many instances, the overhead can measurably slow the application. Balance the probe interval against how fast you need to detect failures.
- **Wrong alarms.** Thresholds that are too tight cause false positives on transient problems. Thresholds that are too loose delay detection.
- **Shallow answers.** A reply proves only that the process can respond. It does not prove that dependencies work.

A monitor pings a service and declares failure when the echo does not arrive in time.

```mermaid
sequenceDiagram
    participant M as Monitor
    participant S as Service
    M->>S: Echo request
    S-->>M: Echo reply
    M->>S: Echo request
    Note over M: No reply within time threshold
    M->>M: Declare failure
```

## Checks

- The document states how long a pinging component waits for an echo before declaring failure.
- Timeouts and failure thresholds are configured so transient failures such as network delays do not trigger unnecessary actions.
- The probe interval is balanced against probe overhead, especially across many instances.
- The document states whether health checks are shallow or also test downstream dependencies.

## Related

- [Fault Detection Tactic](https://arc.fuet.ch/concepts/tactics/availability-tactics-fault-detection.md)
- [Heartbeat](https://arc.fuet.ch/concepts/tactics/heartbeat.md)
- [Availability Tactic](https://arc.fuet.ch/concepts/tactics/availability-tactic.md)
- [Load Balancer](https://arc.fuet.ch/concepts/tactics/load-balancer.md)
- [Request-Reply](https://arc.fuet.ch/concepts/integration/request-reply.md)
- [Synchronous vs. Asynchronous Communication](https://arc.fuet.ch/concepts/integration/synchronous-vs-asynchronous-communication.md)
- [Availability](https://arc.fuet.ch/concepts/quality-attributes/availability.md)
- [Architectural Tactic](https://arc.fuet.ch/concepts/tactics/architectural-tactic.md)

## Sources

- [Availability | Learning](https://hanfak.gitbook.io/workspace/general-paradigms/design-architecture-aims/quality-attributes/availability-2) — hanfak.gitbook.io, accessed 2026-11-08
- [RFC 792: Internet Control Message Protocol | RFC Editor](https://www.rfc-editor.org/info/rfc792/) — rfc-editor.org, accessed 2026-11-08
- [Health Endpoint Monitoring Pattern - Azure Architecture Center | Microsoft Learn](https://learn.microsoft.com/en-us/azure/architecture/patterns/health-endpoint-monitoring) — learn.microsoft.com, accessed 2026-11-08
- [Liveness, Readiness, and Startup Probes | Kubernetes](https://kubernetes.io/docs/concepts/workloads/pods/probes/) — kubernetes.io, accessed 2026-11-08