Provider Watch

1. Buy a provider slot: Your watches → Provider watchdog slot → Buy slots.
2. Choose New watch and, in 1. Choose a type, pick Provider FSP monitoring.
3. In 2. What to monitor, choose the Network and enter the Provider identity address (0x…). That is the identity address registered in the EntityManager, not the submit or signing policy address.
4. Keep the defaults in 3. Signals for a start. You can fine-tune them later.
5. In 4. Recipients, limit provider alerts to a few channels. Busy days can bring several alerts, and a team group is often the best place for them.
6. Save. The watch card shows OK, Problem or Not checked, and Show details lists the latest readings.

Each watch covers one network. If you run your provider on Flare and Songbird, create two watches with one provider slot each.

• FTSO: commit, reveal and signature in every voting round.
• FDC: bitvote, signature, unconfirmed consensus requests, bitvote length and unexpected submit1 transactions.
• Offences: reveals that do not match the commit, a wrong signer, a missed signature grace period and FDC reveal offences.
• Transactions: a submission transaction failed.
• Fast Updates: inactivity that is statistically unlikely for your weight.
• Registration: registration for the next reward epoch still pending, or the identity missing from the active signing policy.
• Validator: none of your NodeIDs is a current validator, plus a connectivity early warning that is off by default.
• Balances: an hourly check of the submit, signature and signing policy addresses, with a warning and a critical level in FLR or SGB.
• Rewards: one summary per reward epoch of your unclaimed rewards above a minimum.
• Minimal Conditions: early warnings for anchor feeds and FDC participation.
• System: Monitoring availability, which is always on.

Every signal with its parameters and defaults is described in the signal reference.

Most FTSO and FDC signals wait for 2 bad rounds in a row before they alert. A voting round lasts 90 seconds.

• 14:00:00, round 1467688: commit missing. First round in a row, no alert.
• 14:01:30, round 1467689: commit missing again. Alert FTSO commit, naming round 1467688 as the first round.
• 14:03:00, round 1467690: commit on time. Recovery notice.

A single hiccup after a restart therefore stays quiet, while a real outage is reported after about 3 minutes. You change the value per signal with Consecutive rounds.

Offences, failed transactions and unexpected FDC submit1 transactions alert at the first occurrence. The most important one is Signature grace missed: a signature that misses the grace period no longer counts for the rewards of that round, so waiting for a second round would only cost more.

The alert names only the phases that were really affected. For each of them it adds a link to the transaction in the explorer. If only the FDC signature missed its grace period, you see one link; if FTSO and FDC both did, you see two.

This signal fires only when none of the NodeIDs registered for your identity is a current validator. If no NodeID is registered at all, the signal does not apply.

Example: you run two validators whose stakes end at different times. The stake of one ends, and you renew it by reinvesting after it expired. During that gap the other validator is still listed, so there is no alert. Only if both are gone at the same time do you get an alert.

The signals Anchor early warning and FDC early warning count what the analyzer observed in a window of 2, 4 or 6 hours. If your share falls below the threshold, 80% by default, and at least the minimum number of observations exists, you are warned. FDC rounds without consensus are left out.

This is an early indicator, not the official decision. Whether your provider met the minimal conditions is decided by the network at the end of the reward epoch.

The provider watch relies on our FSP analyzer, which reads every voting round from the chain. If its data is older than 10 minutes, you get the alert Monitoring availability, and the other alerts of this watch pause instead of guessing. When fresh data arrives, you get a recovery notice and monitoring continues.

1. Read the alert: signal, network, round and, where available, the transaction links.
2. Open the signal in the signal reference, or use What does this mean? in the Alert history. It lists typical causes and what you can do.
3. Check your submitter, signer and node logs around that round.
4. Wait for the recovery notice. If it does not come within a few rounds, the problem is still there.
5. If the alert was harmless, for example during planned maintenance, raise Consecutive rounds or pause the watch for the maintenance instead of switching the signal off.