Why your avalanche subnet validator keeps getting kicked offline

26 September 2026

Your avalanche-chain/avalanche-subnet-consensus-mechanism/">Avalanche subnet validator is being kicked offline because it fails to meet one or more of the continuous availability, resource, or configuration requirements imposed by the subnet’s validation logic and the underlying Avalanche network. The most common causes are insufficient uptime, misconfigured node software, inadequate hardware resources, or running out of AVAX or the subnet’s native gas token for fee payments.

Validator Uptime Requirements

Every Avalanche subnet defines a minimum uptime threshold that validators must maintain. If your validator drops below this threshold over a sliding window - typically measured in hours or days - the subnet’s consensus mechanism will remove it from the active validator set.

• Node crashes and restarts: A single crash can reset your uptime counter. Even if your node restarts quickly, the lost time counts against you.
• Network connectivity issues: Packet loss, high latency, or intermittent disconnections from the Avalanche P-Chain or your subnet’s peers can cause missed validation rounds.
• Scheduled maintenance: If you take your node offline for updates or hardware work without coordinating with the subnet’s governance, the downtime counts as missed validation.

To check your validator’s current uptime, query the subnet’s chain state using the AvalancheJS SDK or a custom RPC call. The exact threshold and window are set by the subnet creator and are visible in the subnet’s configuration parameters.

Resource Constraints

Avalanche validators must maintain specific hardware and software resources. If your machine cannot keep up, the node will fall behind and eventually be ejected.

CPU and Memory

Each subnet runs its own Virtual Machine (VM). Some VMs are lightweight, but others, especially those running Ethereum-compatible EVM subnets, require significant processing power. If your CPU is consistently at 100% or memory usage exceeds available RAM, the node will miss block proposals and attestations.

Check your current usage: 1. SSH into your validator machine. 2. Run htop or top to see CPU and memory consumption. 3. Compare against the subnet’s recommended specs (listed in the subnet’s documentation or by the subnet owner).

Disk Space

Validators store the entire blockchain history for the subnet they validate. If disk space runs out, the node cannot write new blocks and will disconnect. Subnets with high transaction volume can accumulate tens of gigabytes per day.

Monitor disk usage: - Use df -h to check available space. - Set up a cron job to alert you when disk usage exceeds 80%.

Network Bandwidth

Avalanche validators broadcast and receive many messages per second. If your internet connection has low bandwidth or high latency, you will miss attestation windows. A connection speed of at least 100 Mbps download and 50 Mbps upload is a baseline for most subnets. Higher-traffic subnets may require more.

Configuration Errors

A misconfigured validator node is a common reason for being kicked offline.

Bootstrapping Issues

When a validator restarts, it must bootstrap by syncing the latest blockchain state. If the node is configured to bootstrap from a snapshot that is too old, or if the snapshot download fails, the node will never catch up and will be marked as offline by other validators.

Solution: Always use the latest snapshot from the subnet’s official source or sync from genesis if the chain is small.

Improper Peer Connection

Validators need a stable set of peers. If your node’s bootstrap IPs are stale or the subnet’s peer list has changed, your node may not find enough validators to connect to.

Check peer count: - Query the node’s API for peers count. A healthy validator should have at least a few dozen peers.

Stale or incorrect configuration file

The config.json or command-line flags for your AvalancheGo node must match the subnet’s requirements. Common mistakes include: - Wrong chain ID. - Incorrect fee token address. - Missing or outdated VM binary.

Always compare your configuration against the subnet’s latest published example.

Fee Payment Failures

Even if your validator runs perfectly, it can be kicked offline if it runs out of the subnet’s fee token. Each validation round requires a small fee to be paid from the validator’s address. If the balance drops to zero, the validator cannot participate.

• AVAX on the P-Chain: For subnets that use AVAX as the fee token, ensure your P-Chain wallet has enough for ongoing validation fees.
• Custom native gas token: If the subnet uses a different token, monitor that balance separately.

Set up automated alerts for low balances on the relevant chain.

What to do when you are kicked

1. Identify the cause: Check your validator logs for error messages. Common phrases include “insufficient uptime”, “out of disk space”, or “fee insufficient”.
2. Fix the issue: Address the root cause - restart with correct config, add disk space, top up fees.
3. Re-register: If the subnet allows, re-register your validator by calling the appropriate smart contract or governance function. Some subnets have a cooldown period before you can rejoin.
4. Monitor closely: After re-registration, watch logs and metrics for at least 24 hours to ensure stability.

Preventing Future Kicks

• Automate uptime monitoring with a tool like Prometheus and Grafana.
• Set up redundancy - run a backup validator on a separate machine in a different data center.
• Subscribe to the subnet’s official communication channels for configuration updates and maintenance windows.
• Keep your AvalancheGo software updated to the latest stable release.

If your validator keeps getting kicked despite addressing all these points, the subnet’s validation rules may have changed, or you may be running an incompatible VM version. Contact the subnet owner or check the subnet’s governance forum for known issues.

Back to avalanche