A missing drand beacon can mean several different things: the required round is not due yet, a worker is waiting for its delivery turn, a relay request failed, or a submission was rejected. Start by identifying the first stage for which you lack evidence. A missing assignment alone does not identify the cause.
This diagnostic follows the published Congrid drand reference and the versioned verifierd implementation. The example is hypothetical; it is not a report of a production incident. For context, read the drand core guide and delivery timeline.
Begin with the requirement
Record the observation time in UTC, the chain and software version, and the exact Content Grid verification round. The documented workflow queries the chain's drand requirement; record whether drand is enabled, whether a requirement is pending or already submitted, the required drand round, network chain hash, and scheduled beacon time. Compare observations taken at the same chain height or time where possible.
If the requirement is disabled or not pending, first establish whether that state is expected for the deployment. If it is already submitted, inspect assignment creation separately. If a required round is pending, move to the timing check. Do not assume that a repository default represents the live configuration.
Check the clock and the worker's turn
Compare the current UTC time with the required beacon's scheduled time. The cited verifierd code waits for that time before fetching. A round announced in advance can therefore be absent without demonstrating a fault.
Next compare the worker's relay rank and eligible time with its poll time. The published design uses a primary and staggered fallbacks. A fallback waiting before its eligible time is different from an eligible worker reporting a failed request. Polling delays and clock differences can also affect the observation. See the round mapping and delivery guide for worked timing examples.
The published verifierd reference describes readiness information. At revision ed2f617, fields include drand_pending, drand_submitted, drand_required_round, drand_required_beacon_unix, drand_relay_rank, drand_relay_not_before_unix and last_drand_error. Check the documentation for the deployed version: a local health snapshot is evidence about that worker, not by itself proof of chain acceptance.
Follow the first failing stage
| Observation | Next evidence to compare | What it does not establish |
|---|---|---|
| Scheduled time or worker eligibility is in the future | UTC clock, required beacon time and rank eligibility | A relay outage |
| Eligible worker reports a timeout or HTTP error | Endpoint, exact requested network and round, time, and response details | That the beacon proof is invalid |
| A response names a different round or network | Chain requirement, chain hash, request and response fields | That a newer “latest” response is acceptable |
| Proof or digest check fails | Network identity, scheme, public key, proof fields and verifier result | That every relay or drand node is down |
| Submission fails | Transaction result, rejection details and current chain requirement | That retrieval itself failed |
| Beacon accepted, assignments absent | Chain state and subsequent assignment evidence for the same round | That the HTTP request was the cause |
The drand API documentation lists public endpoints and client libraries. Compare the exact required round and network; a successful response is not proof of a valid signature or on-chain acceptance. The signature verification checklist separates those checks.
Walk through a hypothetical case
Imagine the chain reports a pending round scheduled at 12:00 UTC. At 12:00:20, a rank-one worker's recorded eligibility is 12:01. Its lack of a submission at 12:00:20 is consistent with waiting; it does not prove a network failure.
At 12:01:20, suppose its next poll reports an HTTP timeout. Capture the endpoint and exact round, then check the chain requirement again: another worker may already have filled it. If the requirement is still pending, the timeout narrows the investigation to a retrieval attempt. It does not establish why that attempt timed out or whether another endpoint has the beacon. If a later response is retrieved, compare its identity and proof before looking for the chain's acceptance record.
Make a useful handoff record
Keep a short, timestamped record of the chain and worker version; requirement and network identity; scheduled and eligible times; endpoint and request result; proof or digest result; submission response; and final chain state. Redact credentials and private keys from any shared logs. Preserve uncertainty when a stage was not observed.
The verifier monitoring checklist covers broader service health, and the verifier guide explains the operator role. The goal is to locate the first unsupported transition, then investigate that transition with evidence.