Bitcoin node maintenance checklist

A Bitcoin node is infrastructure, not a pet. The goal is boring uptime: stay near the tip, keep disk headroom, apply verified upgrades, and avoid fiddling with RPC. This checklist is the maintenance rhythm that matches the commands library and the setup guide.

What “healthy” looks like

After initial sync, a healthy node usually shows:

• verificationprogress at or very near 1.0
• initialblockdownload false
• At least a few peers (getconnectioncount > 0)
• Comfortable free disk (do not live at 95%+ full)
• systemd (or your process supervisor) reporting active without crash loops

If you are still in IBD, maintenance means triage — not polishing configs. Use the sync and disk sections on commands first.

Weekly checklist (5 minutes)

• Confirm bitcoind is running (systemctl status bitcoind or pgrep -a bitcoind)
• Check tip health with bitcoin-cli getblockchaininfo
• Confirm peers with bitcoin-cli getconnectioncount
• Glance at disk free space (df -h on the datadir filesystem)
• Skim recent logs only if something looks wrong (journalctl -u bitcoind -n 40)

$ bitcoin-cli getblockchaininfo
$ bitcoin-cli getconnectioncount
$ df -h ~/.bitcoin

Monthly checklist

• Review prune vs full needs — still enough disk for growth? See pruned vs full
• Confirm OS updates applied (unattended-upgrades or your patch cadence)
• Re-check RPC is localhost-only (ss -tlnp | grep 8332) — security basics
• VPS only: review bandwidth usage and volume size against provider quotas
• Note Bitcoin Core version (bitcoind --version) vs latest stable on bitcoincore.org

Monthly is also when you decide whether inbound port 8333 still matches your threat model. Opening it helps the network; it also advertises that you run Bitcoin. Tor operators should re-read Tor and privacy.

Release-day upgrade ritual

When a new stable Bitcoin Core ships:

1. Read the release notes for breaking config changes
2. Download from bitcoincore.org and verify signatures
3. Stop cleanly: bitcoin-cli stop or systemctl stop bitcoind
4. Install binaries to the same path your unit uses
5. Start and confirm getblockchaininfo returns promptly
6. Watch logs for a few minutes — then leave it alone

$ bitcoind --version
$ sudo systemctl stop bitcoind
# verify + install new binaries (see /setup/)
$ sudo systemctl start bitcoind
$ bitcoin-cli getblockchaininfo
$ journalctl -u bitcoind -n 50 --no-pager

When to leave the node alone

Healthy nodes do not need daily restarts, mempool “tuning,” or random conf experiments. Avoid:

• Exposing RPC “just for a dashboard”
• Deleting files under blocks/ or chainstate/ by hand
• Running untrusted third-party “node optimizer” scripts
• Stacking every self-host app on the same undersized disk as the chain

If you want wallet indexing (Electrum server, etc.), treat it as a separate capacity decision — RAM and disk — not a maintenance checkbox. Start with whether you even need a node: do you need a node?

Failure modes worth a page, not a panic

• Progress stuck — slow disk, no peers, or normal IBD plateaus; use commands before reinstalling
• Disk climbing — expected on full nodes; prune or expand before 100%
• Service restart loops — permissions, corrupt stop, or out-of-space; read journald
• RPC refused — often “working as designed” with localhost binding

Print this page or keep the checklists open on your phone. The point is a repeatable habit, not a second career as a sysadmin.

Home vs VPS maintenance differences

On home hardware you own the power, the disk, and the LAN. Watch for silent UPS failures, full root partitions from unrelated downloads, and router changes that drop inbound 8333. On a VPS you also watch provider emails about host maintenance, bandwidth graphs, and volume size. The Bitcoin Core checks are the same; the failure domains differ. Keep provider API keys off the node image when you can.

If you travel often and leave a home node unattended, prefer systemd restart policies and disk alerts over SSH-ing from random networks. Remote admin belongs behind your own VPN or a jump host — not an open RPC port. Security baseline: security basics.

Logs worth keeping vs logs worth ignoring

Most debug.log chatter is normal peer churn. Act on repeated disk errors, LevelDB complaints, or crash loops in journald. Ignore the urge to paste full logs into public chats — they can include IPs and paths. Redact first. The commands process section shows safe, short tails.

Capacity planning without spreadsheets

Once a year, re-check whether prune still matches your goals and whether the disk still has months of growth headroom. Full-node operators should assume multi-hundred-gigabyte growth over years. Pruned operators should still leave OS headroom. Revisit pruned vs full if your use case changed (for example, you now want to serve historical blocks or run heavier indexers).

FAQ