A missed attestation does not always mean your Ethereum validator is down

Kevin Major · July 30, 2026

A missed attestation alert tells you that something did not land. It does not, by itself, tell you that your validator is down.

That distinction matters. Restarting a healthy node after an isolated timing miss creates risk without fixing anything. Ignoring a run of more serious misses can leave an actual node problem unattended.

The useful question is not simply, “Did my validator miss an attestation?” It is:

Which part of the attestation missed, and did the pattern continue?

Ethereum records three participation components for an attestation: source, target, and head. They are related, but they are not interchangeable. Understanding that ladder turns a generic missed-attestation notification into a diagnostic signal.

One attestation, three participation flags

An Ethereum validator is assigned an attestation duty once per epoch. Its attestation includes the validator's view of:

The Ethereum attestation documentation describes how attestations are created, propagated, aggregated, and included. The exact participation conditions live in get_attestation_participation_flag_indices in the consensus specification.

Head has the strictest timing requirement. It is also conditional on matching target and source. That means these are not three independent coin flips: under the specification, a validator cannot earn timely head participation while missing target or source participation.

Think of the result as a depth gauge, with one wrinkle:

• Head only missed: the miss stopped at the most timing-sensitive layer.
• Head and target missed: the problem went deeper.
• Head, target, and source missed: the attestation failed across the full participation ladder.
• Head and source missed, target earned: the odd one out. Source has a tighter inclusion window than target—5 slots against 32—so an attestation that was correct but included late can lose head and source while still earning target.

The matching conditions nest; the timeliness deadlines do not. That last shape is a late-inclusion signature rather than an incorrect vote.

Head has the strictest timing requirement

The head vote depends on the exact block the validator saw at its assigned slot and whether the attestation was included at the minimum delay. A block that arrives late, slow propagation, a short reorganization, or an inclusion hiccup can cost the head component even when target and source land.

An isolated head-only miss is therefore weak evidence that the validator itself is failing. It is not zero evidence. Repeated head-only misses can still point to local latency, poor peering, clock problems, disk pressure, or an overloaded machine.

The careful rule is:

Head alone must be included at the minimum delay to earn timely participation. A head-only miss can reflect block propagation or inclusion timing. Target or source misses should make you inspect the node—especially when they happen in consecutive epochs.

That wording is deliberately not absolute. Source and target also carry inclusion deadlines. A prolonged network or inclusion failure can cost them without a local hardware or client fault.

Target or source misses deserve a closer look

A target or source miss is a stronger operational signal because it means more than the strictest timing window was missed—either the vote itself was wrong, or inclusion was slow enough to breach a wider deadline.

Possible causes include:

• The validator client or consensus client was offline or restarting.
• The consensus client was not synchronized or was in optimistic sync.
• The validator could not communicate reliably with its beacon node.
• The host was starved for CPU, memory, or disk I/O.
• The system clock was wrong.
• Connectivity or peer quality was poor for long enough to affect inclusion.
• The network experienced a broader propagation or inclusion failure.

An all-three miss is consistent with an outage or a prolonged connectivity/inclusion failure. It is a reason to investigate promptly, not a proof of one specific root cause.

When target or source misses repeat, check the validator-client and consensus-client logs, synchronization state, peer count, clock synchronization, disk health, free space, CPU pressure, and recent restarts or upgrades. Also check whether other operators are reporting a network-wide incident before changing a healthy setup.

Two misses with very different meaning

Two real mainnet events recorded by Eyrium show why the component breakdown matters.

Event 1: head only

At epoch 464570:

The validator landed target and source. Only head missed. The total difference was 0.000002129 ETH: financially trivial as a single event and, in isolation, a weak reason to touch the node.

Event 2: head and target

At epoch 464347:

The negative target value is important. This validator did not merely forgo the ideal 3,957 gwei target reward; it also received a 4,095 gwei penalty. The total difference was about 4.8 times the head-only example.

Even 10,163 gwei is only 0.000010163 ETH. The point is not to dramatize the loss from one epoch. The point is that the second event carries a materially stronger diagnostic signal.

Reward difference should be measured, not guessed

The Beacon API reports actual source, target, and head reward components. It also reports ideal rewards for a validator's effective-balance bucket—what the validator would have earned had it satisfied each component.

Eyrium records those ideal values with the event and calculates:

loss = Σ (ideal component reward - actual component reward)

Because actual rewards are signed values, the calculation handles penalties correctly. In the target example:

3,957 - (-4,095) = 8,052 gwei

The result is chain-derived for that validator and epoch. It is not a generic estimate.

When the Beacon API does not return ideal rewards for an epoch, Eyrium records the actual components without a computed difference rather than substituting an estimate.

Suppress the notification, not the evidence

There are two different jobs in validator monitoring:

1. Preserve a complete record for later analysis.
2. Interrupt the operator only when the event meets their paging policy.

Treating those as the same job is how alert fatigue starts.

Eyrium provides two account-wide controls for missed-attestation notifications:

• Ignore head-only misses: off by default. When enabled, it suppresses a notification only when head is non-positive while target and source remain positive.
• Minimum streak: an integer from 1 to 10, defaulting to 1. A notification fires only when the current real miss is preceded by enough consecutive real misses to satisfy the chosen streak.

The interaction matters. If head-only suppression is enabled, a head-only miss does not merely disappear from a target/source streak—it breaks the streak.

For example, with a minimum streak of 3:

target miss → head-only miss → target miss

does not notify. The middle epoch landed target and source, so the validator was not continuously failing under that policy.

Two edges are worth knowing:

• A streak greater than 1 has a warm-up period. If there are not enough prior epoch samples, the notification is suppressed.
• A suppressed miss is still recorded in event history and remains available through the read-only API. The record is preserved; only the interruption is withheld.

There is no universal “right” threshold

Do not copy another operator's streak setting blindly. An isolated home validator, a fleet spread across several hosts, and validators sharing one machine can have very different failure patterns.

Review your own event history first:

• If head-only misses are isolated, you may decide they belong in history rather than notifications.
• If head-only misses repeat, investigate local latency and node health before suppressing them.
• If target or source misses appear, lower your tolerance and inspect the node.
• If misses continue across epochs, treat the streak as an escalating signal.

Eyrium's controls currently apply to the entire account, not to individual validators. An operator with differently behaving validators cannot tune each one independently today. Per-validator filtering is not yet shipped.

What a useful missed-attestation alert should answer

A useful alert should tell you more than “missed”:

• Which of head, target, and source failed?
• Was the component unpaid or penalized?
• What were the actual and ideal rewards?
• What was the precise per-event difference?
• Is this isolated or part of a continuing streak?
• Was the notification delivered, suppressed, or only recorded?

Eyrium's missed-attestation monitoring separates head-only misses from target/source misses, records the component-level reward difference, and lets operators separate event history from notification policy.

Detection is finality-aware: Eyrium processes validator results as the finalized checkpoint advances. It does not promise an artificial “60-second” alert for data that is not yet final.

The free tier monitors one validator with email alerts. Pro monitors up to 200 validators and adds Telegram, iOS/Android push, and signed webhooks. Both tiers include missed-attestation history and suppression controls.

The goal is not fewer facts. It is fewer meaningless interruptions—and enough detail to recognize the interruption that matters.