Failure detector

A distributed-system abstraction that supplies processes with possibly fallible suspicions about crashed peers, classified by completeness and accuracy guarantees.

Version

v2 · 2026-09-19 · History

Domain-specific #

4507

Domain group

Applied Sciences & Engineering

Origin domain

Computer Science & Software Engineering

Subdomain

Distributed Computing → Computer Science & Software Engineering

Core Idea

A failure detector encapsulates extra timing or oracle information needed to reason about failures that pure asynchrony cannot distinguish from delay. Local observations produce evolving suspicion sets; detector classes specify which real crashes are eventually suspected and which correct processes avoid permanent false suspicion. The abstraction is therefore identified by a declared carrier, a transformation or constraint over that carrier, and an invariant that tells an analyst whether the named structure is genuinely present.

The load-bearing residual is not the broad topic of distributed computing. It is A distributed-system abstraction that supplies processes with possibly fallible suspicions about crashed peers, classified by completeness and accuracy guarantees.

How would you explain it like I'm…

The Who's-Gone Guesser

You call to a friend in another room and they don't answer. Maybe they left, or maybe they are just slow to reply. You can't be sure. A failure detector is a helper that makes a best guess about who has really left, and sometimes it guesses wrong.

The Crash-Suspect List

Computers in a network send each other messages, and sometimes one crashes. If messages can be delayed for any amount of time, a computer can't tell a crashed friend from a slow one. A failure detector is a helper that gives each computer a list of friends it suspects have crashed. The list can be wrong and can change over time. Different detectors promise different things, like 'every crashed computer will eventually be on the list' or 'working computers won't stay on the list forever.'

Fallible Crash Suspicion Oracle

In a distributed system where messages can be delayed by any amount (asynchrony), a process can't tell a crashed peer from a slow one. A failure detector is an abstraction that supplies the extra timing or oracle information to help: each process gets a changing set of suspected-crashed peers. Suspicions may be mistaken. Detector classes are defined by two kinds of guarantees: completeness (real crashes are eventually suspected) and accuracy (correct processes aren't permanently or wrongly suspected). Whether something counts as a given detector depends on its suspicion history meeting those guarantees under the stated failure and timing model.

 

A failure detector is a distributed-computing abstraction that supplies each process with possibly fallible suspicions about which peers have crashed. It packages the extra timing or oracle information needed to tell crashes apart from delays, which pure asynchrony cannot do. Each process observes its surroundings locally and maintains a suspicion set that evolves over time. Detector classes are defined by two families of properties. Completeness specifies which actual crashes are eventually suspected. Accuracy specifies which correct processes avoid false suspicion, or at least avoid permanent false suspicion. Whether something counts as a given detector depends on whether its suspicion history satisfies the declared completeness and accuracy properties under the stated failure and timing model. This lets designers state precisely what failure information an algorithm needs. It also keeps them from assuming guarantees the detector does not provide.

Scope of Application

Failure detector belongs to distributed computing and is useful where the analyst can specify asynchronous processes, crash failures, monitoring module, suspicion outputs, timing assumptions, completeness, accuracy and consensus algorithm, then evaluate the suspicion history satisfies the declared completeness and accuracy properties under the stated failure and timing model. The scope is broad within that domain but bounded by the need for the suspicion history satisfies the declared completeness and accuracy properties under the stated failure and timing model. The entry records a descriptive analytical identity; practical use requires the governing domain's evidence, standards, and safety obligations.

Clarity

The abstraction clarifies a crowded vocabulary by making the suspicion history satisfies the declared completeness and accuracy properties under the stated failure and timing model the center of the account. A claim should name the carrier, the governing operation or relation, the applicable assumptions, and the recognition test. A bare label is insufficient because the name Failure detector can be used for a formal identity, an implementation, or a neighboring result unless carrier and convention are stated.

Manages Complexity

Without the abstraction, an analyst must reason directly over many local details: the carrier roles, admissibility assumptions, competing conventions, derived invariants, boundary cases, and proof or validation obligations specific to Failure detector. Failure detector compresses them into the roles in the structural signature. That compression permits comparison across instances without erasing the variables that determine validity. It also exposes which details may be varied safely and which are constitutive.

Abstract Reasoning

1. Identify the carrier. State what the elements, states, objects, or observations are: asynchronous processes, crash failures, monitoring module, suspicion outputs, timing assumptions, completeness, accuracy and consensus algorithm. Reject examples whose alleged carrier belongs to a different problem.
2. Lock the constitutive rule. Express the suspicion history satisfies the declared completeness and accuracy properties under the stated failure and timing model independently of one notation or implementation.

Knowledge Transfer

Knowledge transfers strongly among subfields of distributed computing because they reuse asynchronous processes, crash failures, monitoring module, suspicion outputs, timing assumptions, completeness, accuracy and consensus algorithm, Local observations produce evolving suspicion sets; detector classes specify which real crashes are eventually suspected and which correct processes avoid permanent false suspicion., and type the carrier, state every parameter and convention in the definition, test that the suspicion history satisfies the declared completeness and accuracy properties under the stated failure and timing model, compare the nearest accepted identity, and report counterexamples, uncertainty, and limiting cases.

Relationships to Other Abstractions

Current abstraction Failure detector Domain-specific

Parents (1) — outgoing typed relations

• Failure detector is a kind of Fault Tolerance Prime

  What makes it its own entry: A distributed-system abstraction that supplies processes with possibly fallible suspicions about crashed peers, classified by completeness and accuracy guarantees.

Hierarchy paths (3) — routes to 3 parentless roots

• Failure detector → is a kind of Fault Tolerance → is a kind of Robustness

Show alternative paths (2)

Neighborhood in Abstraction Space

Failure detector sits in a crowded region of the domain-specific corpus (36^th percentile for distinctiveness): several abstractions share nearly its structure, so a description that fits it tends to fit its neighbors too.

Family — Detection Limits & Fault Diagnosis (5 abstractions)

Nearest neighbors

• Terminating Reliable Broadcast — 0.91
• Fault detection and isolation — 0.89
• Happened-before — 0.87
• Run chart — 0.87
• Moving horizon estimation — 0.87

Computed from structural-signature embeddings · 2026-10-25