Signals

Each watch type has one or more signals. A signal checks one condition, for example a missing FTSO commit or a credit balance below your limit. In section 3. Signals of the watch editor you can switch each signal on or off, switch its recovery notice, and change its parameters. Reset to defaults restores the standard values.

Signals belong to signal groups such as FTSO, FDC or Balances. Groups matter for routing, because you can send one group to other recipients than the rest; see Recipients and routing.

Every signal in the reference below answers four questions: what is checked, why it matters, typical causes, and what you can do. The same texts appear in the app when you click the info icon next to a signal.

Almost every signal is on by default and sends a recovery notice. The exceptions are marked in the reference below. The signal Monitoring availability of the provider watch is always on and cannot be switched off, because it tells you when monitoring itself is not possible.

Some provider signals have the parameter Consecutive rounds. It keeps a single late or missing submission from waking you up at night. The default is 2.

Example with the default of 2:

• Round 1000: the commit is missing. First round in a row, no alert yet.
• Round 1001: the commit is missing again. Second round in a row, alert.
• Round 1002: the commit arrives on time. Recovery notice, if it is switched on.

If round 1001 had been fine, nothing would have been sent at all. While an alert is active, further bad rounds do not send it again; you get one alert per incident, not one per round. Set the value to 1 if you want to hear about every single miss.

A recovery notice tells you the condition is back to normal. It goes to the same recipients as the alert. If you only care about problems, switch it off per signal.

The cooldown is a per-watch setting called Minimum gap between alerts. It suppresses repeats of the same event within that time, but never a different event such as a recovery notice. How it works in detail is on Messages and quiet hours.

When the Watchdog cannot read a value, for example because a data source is late, it does not treat that as healthy. A round without evidence interrupts a streak of bad rounds, but it never triggers a recovery notice. For the provider watch, the signal Monitoring availability tells you when the analyzer data is older than 10 minutes; while that is the case, the other provider alerts of that watch pause instead of guessing.

1. Open Your watches and choose Edit on the watch.
2. Open section 3. Signals and expand the group you want to change.
3. Switch the signal or its recovery notice, or change a parameter. If a value is out of range, the section shows Check the values in this section, and saving stays disabled until you fix it.
4. Save. The change applies from the next check.

Events for the selected watch target and threshold.

Balance change

Notify when the configured wallet balance moves past its threshold.

• What is checked? Compares the current balance with the previous observation and alerts when the absolute change reaches the threshold in the chosen direction. The first observation sets the baseline.
• Why does it matter? A balance change can indicate an incoming or outgoing transfer you want to track.
• Typical causes: Transfers, gas fees or other balance changes occurred between observations.
• What can I do? Compare the observed amounts with recent wallet transactions and the configured token.
• Signal enabled: on

Events for the selected watch target and threshold.

Price movement

Notify when the configured feed moves past its threshold.

• What is checked? Compares the current USD feed price with the oldest valid point inside the window. Alerts at the percentage threshold, at most once per window; twice the threshold is critical.
• Why does it matter? A large observed price move may deserve attention.
• Typical causes: The current feed price differs from the earlier valid price in the selected window.
• What can I do? Compare timestamps and prices and review the selected window and percentage.
• Signal enabled: on

Events for the selected watch target and threshold.

Provider status

Notify when the provider is unregistered or loses eligibility.

• What is checked? After establishing a baseline, reports loss of registration or eligibility and recovery of either. A provider missing from the dataset is treated as unregistered and ineligible.
• Why does it matter? An unregistered or ineligible provider earns no rewards for its delegators in that reward epoch.
• Typical causes: The registration was missed, or a Minimal Condition was failed with no passes left.
• What can I do? Check the provider on the Flare Systems Explorer (Minimal Conditions and passes) and its registration for the current epoch.
• Signal enabled: on
• Send recovery notice: on

Events for the selected watch target and threshold.

Low credits balance

Notify when your credits balance falls below the configured threshold.

• What is checked? Alerts when the wallet credit balance becomes strictly lower than the configured limit; recovery includes equality with the limit.
• Why does it matter? A low credit balance can affect services that spend credits.
• Typical causes: Credit spending or an adjustment may have moved the balance below your chosen threshold.
• What can I do? Review credit balance and recent entries, then adjust the threshold or replenish if needed.
• Signal enabled: on
• Send recovery notice: on

Events for the selected watch target and threshold.

Reward signing

Notify about open, overdue or missed uptime and rewards signatures.

• What is checked? Checks missing uptime and reward signatures for the just-ended epoch. Open alerts wait two hours after epoch end or first observed reward-data publication; a reward reminder follows after twelve hours, and a concluded unsigned vote is critical.
• Why does it matter? A required provider signature may be pending or may have missed the concluded vote.
• Typical causes: The identity is absent from the observed signer set for uptime or reward data.
• What can I do? Check the epoch, vote state and signing process for the configured identity.
• Signal enabled: on
• Send recovery notice: on

Commit, reveal and signature participation in FTSO voting rounds.

FTSO commit

Missing or late commit in consecutive rounds.

• What is checked? Checks for missing or late FTSO commits in consecutive voting rounds.
• Why does it matter? Without a valid commit your value does not count in that voting round, so you lose its median-closeness rewards. Missed rounds also count against the anchor-feed Minimal Condition (within 0.5% of the median in 80% of rounds per reward epoch).
• Typical causes: FTSO client or Flare System Client stopped or restarting, C-chain indexer behind the chain head, RPC problems, or too little native balance on the submit address.
• What can I do? Check that the system client logs “Submitter submit1 successfully sent tx” every round, that the indexer is at the chain head and that the submit address has funds.
• Signal enabled: on
• Send recovery notice: on
• Consecutive rounds: default 2 (1–20). Number of consecutive bad voting rounds; 2 ignores a single isolated miss. Missing evidence resets the streak, without proving recovery.

FTSO reveal

Missing, early or late reveal in consecutive rounds.

• What is checked? Checks for missing, early or late FTSO reveals in consecutive voting rounds.
• Why does it matter? A commit without a matching reveal is penalised: your value is excluded and the round’s rewards are reduced or forfeited. A missing reveal also removes your random number from the round.
• Typical causes: The client restarted between commit and reveal, the reveal (submit2) was sent too late, or the submit address ran out of funds.
• What can I do? Check the submit2 transactions of the reported rounds, the log timing between commit and reveal, and whether the client was restarted in between.
• Signal enabled: on
• Send recovery notice: on
• Consecutive rounds: default 2 (1–20). Number of consecutive bad voting rounds; 2 ignores a single isolated miss. Missing evidence resets the streak, without proving recovery.

FTSO signature

Missing or early signature in consecutive rounds.

• What is checked? Checks for missing or early FTSO signatures in consecutive voting rounds; grace-period misses are a separate signal.
• Why does it matter? Signature rewards are paid only for signatures on the finalised Merkle root that arrive in time. A missing signature loses that share and does not help finalise the round.
• Typical causes: The signing step (submitSignatures) failed or was delayed, the Merkle root could not be computed, or the submit-signatures address lacks funds.
• What can I do? Look for “Submitter submitSignatures successfully sent tx” in the system client logs and check the balance of the submit-signatures address.
• Signal enabled: on
• Send recovery notice: on
• Consecutive rounds: default 2 (1–20). Number of consecutive bad voting rounds; 2 ignores a single isolated miss. Missing evidence resets the streak, without proving recovery.

FDC bitvotes, signatures and agreement with consensus requests.

FDC bitvote

Missing, early or late bitvote in consecutive rounds.

• What is checked? Checks for missing, early or late FDC bitvotes in consecutive voting rounds.
• Why does it matter? Without a timely bitvote you take no part in that round’s FDC consensus. The FDC Minimal Condition requires successful participation in 60% of voting rounds per reward epoch.
• Typical causes: FDC client or verifiers unavailable, an attestation source (e.g. BTC, DOGE or XRP node) out of sync, or the bitvote sent outside the choose phase (90–135 s into the round).
• What can I do? Check the FDC client logs and each verifier’s /health endpoint, and whether the bitvote transaction lands inside the choose phase.
• Signal enabled: on
• Send recovery notice: on
• Consecutive rounds: default 2 (1–20). Number of consecutive bad voting rounds; 2 ignores a single isolated miss. Missing evidence resets the streak, without proving recovery.

FDC signature

Missing or early signature in consecutive rounds.

• What is checked? Checks for missing or early FDC signatures in consecutive voting rounds.
• Why does it matter? FDC participation counts only when you submit the correct Merkle root. Without your signature the round does not count towards the 60% requirement, and you lose its signature rewards.
• Typical causes: The FDC Merkle root could not be built or signed, verifier data was incomplete, or the submit-signatures address lacks funds.
• What can I do? Check FDC client and verifier health and the submitSignatures transactions of the reported rounds.
• Signal enabled: on
• Send recovery notice: on
• Consecutive rounds: default 2 (1–20). Number of consecutive bad voting rounds; 2 ignores a single isolated miss. Missing evidence resets the streak, without proving recovery.

Unexpected FDC submit1

An FDC submit1 was observed.

• What is checked? Reports an observed FDC submit1 when submission data is available.
• Why does it matter? This submission phase is unexpected for FDC and warrants a configuration check.
• Typical causes: A submitter may be using the wrong protocol or submission method.
• What can I do? Inspect the reported transaction and the submitter protocol configuration.
• Signal enabled: on
• Send recovery notice: on

Unconfirmed consensus requests

Consecutive rounds with unconfirmed consensus requests; one aggregate alert.

• What is checked? Checks consecutive voting rounds with at least one unconfirmed consensus request and emits one aggregate alert.
• Why does it matter? Requests the consensus confirmed but you did not usually mean your verifier could not check them. Without that data you often cannot build and sign the consensus Merkle root, and the round does not count for you.
• Typical causes: A verifier for one chain is down or behind, or its data source (e.g. a BTC, DOGE or XRP node) is not synced.
• What can I do? Find out which chain or attestation type the unconfirmed requests belong to and check that verifier’s health and sync status.
• Signal enabled: on
• Send recovery notice: on
• Consecutive rounds: default 2 (1–20). Number of consecutive bad voting rounds; 2 ignores a single isolated miss. Missing evidence resets the streak, without proving recovery.

FDC bitvote length

Bitvote length differs from the verified unique request count.

• What is checked? Checks whether the FDC bitvote length matches the verified unique request count.
• Why does it matter? A bitvote of the wrong length cannot be matched to the round’s requests, so it does not count towards the consensus or your FDC participation.
• Typical causes: The FDC client saw a different set of requests than the chain, e.g. because of indexer lag or a client version problem after an upgrade.
• What can I do? Check that the C-chain indexer is at the chain head and that the FDC client runs the current version, then compare the request count in the logs.
• Signal enabled: on
• Send recovery notice: on

Evidence of mismatched reveals, wrong signers or missed signature grace periods.

Reveal offence

Commit and reveal do not match; immediate critical alert.

• What is checked? A verified FTSO commit/reveal mismatch triggers an immediate critical alert.
• Why does it matter? A reveal that does not match its commit is penalised: the round’s rewards are reduced or forfeited, and penalties can make an epoch’s reward claims negative.
• Typical causes: Commit and reveal were built from different data, typically after a restart, or two running instances submit with the same addresses.
• What can I do? Make sure exactly one client submits for your addresses and check the logs around the reported round.
• Signal enabled: on
• Send recovery notice: on

Wrong signer

Signature does not match the signing policy address.

• What is checked? Checks whether an FTSO or FDC signature has a signer mismatch against the signing policy address.
• Why does it matter? A signature from the wrong key is not counted for your weight. You lose the signature rewards, and it does not help finalise the round.
• Typical causes: The client signs with a key that is not your entity’s registered signing policy address, e.g. after a key change or a wrong key in the configuration.
• What can I do? Compare the signer of the reported transaction with the signing policy address registered for your identity and correct the configured signing key.
• Signal enabled: on
• Send recovery notice: on

Signature grace missed

Signature missed the reward grace period.

• What is checked? Checks whether an FTSO or FDC signature missed its reward grace period.
• Why does it matter? Signatures within the 10-second grace period after signing starts are always rewarded. Later ones count only if they still arrive before finalisation, which usually follows quickly.
• Typical causes: A slow RPC or indexer, a busy host, or queued transactions on the submit-signatures address.
• What can I do? Compare signing start and your signature transaction in the logs, and check RPC response times and host load.
• Signal enabled: on
• Send recovery notice: on

FDC reveal offence

Bitvote covers the consensus but a valid signature is missing.

• What is checked? Reports the analyzer’s FDC reveal offence: the bitvote covers consensus but a valid signature is missing.
• Why does it matter? When your bitvote covers the consensus you are expected to sign the resulting Merkle root. The analyzer treats a missing valid signature as an FDC offence, and penalties can reduce your epoch rewards.
• Typical causes: The FDC signing step failed after the bitvote, often because verifier responses were missing and the Merkle tree could not be built.
• What can I do? Check the FDC client and verifier health for the reported round and the submitSignatures transaction.
• Signal enabled: on
• Send recovery notice: on

Failed transactions in the monitored submission phases.

Failed transaction

A submission phase failed.

• What is checked? Reports a failed transaction in one of the five monitored submission phases.
• Why does it matter? A reverted submission costs gas, and its data is not recorded, so that phase counts as missed for the round.
• Typical causes: Nonce conflicts from two clients on the same address, too little gas, a sender address not registered for the current epoch, or a contract revert after a protocol upgrade.
• What can I do? Open the reported transaction in the explorer, read the revert reason and make sure only one client uses each submit address.
• Signal enabled: on
• Send recovery notice: on

Fast Updates activity relative to signing weight and elapsed blocks.

Fast Updates inactivity

Alert when inactivity is statistically unlikely. Block-count warnings are off by default.

• What is checked? Compares the modeled probability of no Fast Updates with your threshold, using signing weight and elapsed blocks. The optional block warning uses 1% of the reward-epoch block count.
• Why does it matter? Fast Updates (block-latency feeds) are part of the Minimal Conditions: you must submit at least 80% of your expected updates per reward epoch, unless your weight is below 0.2% of the total.
• Typical causes: The Fast Updates client stopped, its accounts ran out of gas funds (“insufficient funds”), or the sortition key is not registered.
• What can I do? Check the Fast Updates client logs and the balances of all Fast Updates accounts. With low weight, long gaps between selections are normal.
• Signal enabled: on
• Send recovery notice: on
• Probability threshold: default 1E-7 (1E-15–0.1). A smaller probability threshold requires stronger statistical evidence of Fast Updates inactivity.
• Enable block-count warning: default off. Also warn when blocks without updates reach 1% of the reward-epoch block count; disabled by default.

Next-epoch registration and active signing policy membership.

Next epoch registration

Alert once when registration remains pending beyond the configured delay.

• What is checked? Checks whether registration for the next reward epoch is still missing after the configured delay from registration opening.
• Why does it matter? Missing the registration for a reward epoch means no participation and no FSP rewards for that whole epoch, and your passes are reset to zero.
• Typical causes: The system client was not running during the 30-minute registration window, the registration transaction failed, or an entity address lacked funds.
• What can I do? Look for “Voter … registered for epoch …” in the system client logs and make sure the client runs through the registration window; registration is only possible then.
• Signal enabled: on
• Send recovery notice: on
• Delay in minutes: default 15 (1–1,440). Wait this many minutes after registration opens before warning about a missing registration.

Signing policy membership

Identity is not in the active signing policy.

• What is checked? Checks whether the identity is absent from the active signing policy.
• Why does it matter? Only entities in the active signing policy can submit, sign and earn rewards in the current reward epoch.
• Typical causes: The registration for this epoch was missed or did not go through.
• What can I do? The current epoch cannot be joined any more. Make sure the next registration succeeds and check the logs of the last registration window.
• Signal enabled: on
• Send recovery notice: on

Native funds at provider operational addresses used for transactions.

Low operational balance

Hourly native balance check of submit, signatures and signing policy addresses.

• What is checked? Checks cached native balances of operational addresses against warning and critical thresholds; a read failure cannot prove recovery.
• Why does it matter? Low native funds can prevent operational transactions from paying gas.
• Typical causes: Gas spending or outgoing transfers may have reduced an operational address balance.
• What can I do? Check which address is low and its recent transactions before replenishing it.
• Signal enabled: on
• Send recovery notice: on
• Warning below (FLR/SGB): default 25 (0.001–1,000,000). Warn when a readable native balance is strictly below this amount.
• Critical below (FLR/SGB): default 5 (0–1,000,000). Escalate a low-balance alert below this amount; it must not exceed the warning threshold.

Availability and freshness of the monitoring data.

Monitoring availability

Always on. Pauses provider alerts while the analyzer or its results are stale.

• What is checked? Always checks analyzer health. Missing, failed or more than ten-minute-old runs or round data pause provider evaluation.
• Why does it matter? Stale monitoring cannot reliably assess provider health.
• Typical causes: The analyzer may have stopped, failed, or stopped receiving complete rounds.
• What can I do? Check analyzer status, last run and indexed round freshness.
• Signal enabled: Always on
• Send recovery notice: on

Observed FTSO and FDC early warnings, separate from official Minimal Conditions decisions.

Anchor early warning

Observed anchor hits below the window threshold; this is not an official eligibility decision.

• What is checked? Checks the observed FTSO anchor hit rate in the selected window once enough recent samples exist. Zero signing weight makes this inapplicable.
• Why does it matter? Officially, anchor-feed estimates must lie within 0.5% of the median in 80% of voting rounds per reward epoch. This window is an early indicator, not the official result.
• Typical causes: Low participation, connectivity interruptions or incomplete observations can lower the measured value.
• What can I do? Check the window, sample count and source freshness before investigating the provider or validator.
• Signal enabled: on
• Send recovery notice: on
• Warning below (%): default 80% (1%–100%). Warn below this percentage after enough fresh observations; recovery requires two percentage points more, capped at 100%.
• Window: default 2 hours. Choose the observation window in hours; this is not a full reward-epoch assessment.
• Minimum observations: default 40 (10–240). At least this many observations are required before evaluating the percentage.

FDC early warning

Observed FDC participation below the window threshold. Rounds without consensus are excluded.

• What is checked? Checks observed FDC participation in consensus rounds with enough recent samples; rounds without consensus and zero signing weight are excluded.
• Why does it matter? Officially, FDC requires successful participation (the correct Merkle root) in 60% of voting rounds per reward epoch. Your threshold here can warn earlier.
• Typical causes: Low participation, connectivity interruptions or incomplete observations can lower the measured value.
• What can I do? Check the window, sample count and source freshness before investigating the provider or validator.
• Signal enabled: on
• Send recovery notice: on
• Warning below (%): default 80% (1%–100%). Warn below this percentage after enough fresh observations; recovery requires two percentage points more, capped at 100%.
• Window: default 2 hours. Choose the observation window in hours; this is not a full reward-epoch assessment.
• Minimum observations: default 40 (10–240). At least this many observations are required before evaluating the percentage.

Observed P-chain connectivity and registered NodeID validator membership.

Validator connectivity

Multiple P-chain viewpoints; warning disabled pending parallel-run verification.

• What is checked? Checks observed validator connectivity across P-chain viewpoints, not official Uptime. This warning is disabled by default.
• Why does it matter? Staking requires 80% total uptime per reward epoch. This is an observed connectivity signal, not the official uptime.
• Typical causes: Low participation, connectivity interruptions or incomplete observations can lower the measured value.
• What can I do? Check the window, sample count and source freshness before investigating the provider or validator.
• Signal enabled: off
• Send recovery notice: on
• Warning below (%): default 80% (1%–100%). Warn below this percentage after enough fresh observations; recovery requires two percentage points more, capped at 100%.
• Window: default 2 hours. Choose the observation window in hours; this is not a full reward-epoch assessment.
• Minimum observations: default 40 (10–240). At least this many observations are required before evaluating the percentage.

Validator not listed

No registered NodeID is a current validator. Check for missing or expired stake. No NodeIDs means not applicable.

• What is checked? Warns only when all known registered NodeIDs are confirmed absent from the current validator set. No NodeIDs or an unknown result do not prove absence.
• Why does it matter? A node that is not an active validator earns no staking rewards, and the staking Minimal Condition requires 80% total uptime per reward epoch.
• Typical causes: The validator’s stake period ended, the node was never added as a validator, or the NodeID linked to the entity changed.
• What can I do? Check the node’s stake end time, renew the stake if needed and confirm the NodeID linked to your identity.
• Signal enabled: on
• Send recovery notice: on

Personal unclaimed rewards of the provider addresses, grouped by epoch.

Unclaimed personal rewards

One summary per epoch of claimable DIRECT/FEE rewards, verified with proofs. Delegator pools are excluded.

• What is checked? Reports personal unclaimed direct and fee rewards above your minimum once per reward epoch; recovery follows when the amount is at or below it.
• Why does it matter? FSP rewards expire after 25 reward epochs (about three months); unclaimed direct and fee rewards are then lost.
• Typical causes: Rewards became claimable, or a claim has not yet appeared in the cached snapshot.
• What can I do? Review the epoch, amount and claim status in your rewards view.
• Signal enabled: on
• Send recovery notice: on
• Minimum amount (FLR/SGB): default 1 (0–1,000,000,000). Alert only when personal unclaimed rewards are strictly greater than this native-token amount.