Seeing 200 OK from an RPC endpoint is reassuring, but it only tells you that the service answered. A blockchain node can still be behind the network, in the middle of synchronization, poorly connected to peers, or under disk and memory pressure while continuing to return responses. In a multi-client setup, one component may also be unhealthy even though the endpoint itself remains reachable.

For teams running self-hosted blockchain infrastructure, availability is therefore only one part of node health. The more useful question is whether the node is current, connected, adequately resourced, and able to serve the application correctly. The checks below cover the signals that matter once a basic HTTP probe is no longer enough.

1. Start with RPC availability — but do not stop there

The simplest health check is whether the RPC endpoint can be reached. That is still worth monitoring, because an unreachable endpoint is an immediate application problem. However, a successful HTTP response only confirms that something answered the request; it does not confirm that the node has a current view of the blockchain.

A better first probe is to send a lightweight JSON-RPC request and validate the result. On an EVM-compatible chain, eth_blockNumber is a simple example. A valid answer gives you more information than a basic reachability check, but the important part is what happens next: the returned block number should keep changing as the network advances.

2. Monitor chain-head freshness

Chain-head freshness matters because a node can continue answering RPC requests after it has stopped keeping up with the network. If the latest block remains unchanged while the network continues producing blocks, the service is still reachable, but the node is serving an outdated view of the chain.

For operations teams, it helps to treat liveness and freshness as separate signals. Liveness answers the question “Can I reach the endpoint?” while freshness asks “Is the node giving me a current view of the chain?” A production application generally needs both.

Depending on the network, useful checks include:

• Current block height
• Whether the height continues advancing
• Latest block timestamp
• Distance from an independent network reference
• Finalization or safe-head progression where relevant

There is no universal amount of acceptable lag for every blockchain. Thresholds should reflect the network’s expected behavior and the amount of delay the application can tolerate.

3. Check synchronization state

A running process is not automatically a synchronized node. Clients usually expose synchronization information that shows whether they are still catching up with the network, and that state should be monitored alongside chain-head progression.

Ethereum makes this especially important because a node includes both an execution client and a consensus client. Those components have different responsibilities and their own peer-to-peer connections, so a single green “Ethereum node: Running” label is too coarse to describe the health of the full setup.

Operators should be able to see whether both components are healthy and progressing. The exact metrics depend on the client, but the operational principle is consistent: preserve component-level visibility instead of reducing the entire node to one status.

4. Watch peer connectivity

Blockchain nodes rely on peer-to-peer connectivity to receive and propagate network information, which makes peer health an important signal. At the same time, peer count should be treated as context rather than a binary alarm: a small temporary change does not automatically mean there is an incident.

What matters is the trend and how it lines up with other signals. If peer connectivity drops while the chain head also stops advancing, the combination is much more informative than either metric on its own.

5. Monitor the machine underneath the node

Resource pressure often appears before a blockchain client fails outright. CPU, memory, disk performance, storage capacity, and network conditions can all affect synchronization and RPC behavior, so the host itself needs to be part of the monitoring picture.

At minimum, watch:

• CPU usage
• Memory usage
• Disk space
• Disk I/O
• Network traffic
• Process restarts
• Process uptime

Disk deserves particular attention because blockchain databases keep growing. A threshold such as “disk below 15%” can be useful, but forecasting is often more actionable: if storage consumption continues at the current rate, when will the disk actually fill up? That gives the team time to respond before capacity becomes an incident.

6. Monitor the RPC methods your application actually uses

Even a synchronized node can still have an application-facing problem. Overall RPC traffic may look normal while a method the application depends on, such as eth_getLogs, starts returning errors or slowing down. A dashboard that shows only total requests per second can miss that completely.

Method-level monitoring is more useful when it includes signals such as:

• Request count
• Error rate
• Overall latency
• Method mix
• Application-side failures

Those signals should then be correlated with client logs and application traces. The goal is not to create hundreds of charts; it is to answer a practical question: are the RPC calls this application actually relies on succeeding as expected?

7. Keep metrics and logs close together

Metrics are usually the fastest way to see that something changed, while logs provide the context needed to understand what the client was doing at the time. Most major blockchain clients expose detailed metrics that can be collected by monitoring systems and visualized in dashboards.

A useful monitoring setup should make it easy to move from a symptom, such as a chain head that stopped advancing, to the component involved and the relevant logs without searching across several unrelated systems.

8. Alert on conditions that require action

Dashboards are useful during investigation, but they do not help much if nobody is watching them when a problem begins. Alerts should therefore focus on conditions that would actually cause an operator to investigate or take action.

Depending on the chain and client, that can include:

• RPC endpoint unreachable
• Latest block no longer advancing
• Latest block becoming too old
• Node falling behind an independent network reference
• Synchronization stalled
• Major peer-connectivity loss
• Disk approaching exhaustion
• Repeated process restarts
• Sustained CPU or memory pressure
• Increased RPC errors

Avoid copying arbitrary thresholds from another team’s dashboard. A reasonable limit for one chain, client, hardware profile, or application may be meaningless for another, so alerting should be tuned to the environment you actually operate.

A simple blockchain-node monitoring checklist

Before calling a self-hosted node healthy, check the following:

✅ Does the RPC endpoint respond?
✅ Does it return a valid result?
✅ Is the latest block current?
✅ Is the chain head continuing to advance?
✅ Is synchronization complete and progressing normally?
✅ If the node has multiple components, are all of them healthy?
✅ Is peer connectivity stable?
✅ Are CPU, memory, disk, and network resources healthy?
✅ Are the RPC methods the application actually uses succeeding?
✅ Are logs available when something changes?
✅ Will someone receive an alert before the application team discovers the problem?

HTTP 200 is a useful availability signal, but it should never be treated as a complete node-health verdict. A self-hosted blockchain node becomes reliable operational infrastructure when the team can see whether it is current, connected, resourced, and serving the application correctly before an incident forces that investigation.

Where Novacula fits

Novacula helps teams launch and manage self-hosted blockchain nodes on their own infrastructure while keeping operational visibility in one place. Its dashboard brings node-health signals into a single operational view, so teams can assess how nodes are behaving without relying on one endpoint check or piecing the picture together only after something goes wrong.

If your team wants to keep control of the infrastructure while simplifying how nodes are deployed, monitored, updated, and operated, Novacula provides an operational layer for managing that lifecycle.

If the control plane becomes temporarily unavailable, a correctly separated self-hosted node architecture should not automatically lose RPC availability. Existing node processes can continue running while management actions wait for connectivity to return. The exact result depends on the node, network, RPC path, and surrounding infrastructure.

If the dashboard used to manage your blockchain nodes disappears for ten minutes, does your application lose RPC access too?

It depends on where the node runs, where the RPC request travels, and which component actually keeps the process alive. Those paths are easy to blur together when everything is green. An outage is a poor time to discover that your architecture diagram skipped one of them.

What happens when the control plane goes offline?

Here is how Novacula separates management from the node runtime, and how to test that separation in a controlled environment. The steps below are a test plan, not the results of an outage experiment.

Draw the four paths first

A self-hosted blockchain node has at least four operational paths. There is the management interface where an operator requests a change. There is the connection that carries that desired change to software in the customer’s infrastructure. There is the node process, which syncs with its peers and uses local compute and storage. Finally, there is the application’s route to its RPC endpoint.

In Novacula, the Hub is the management service. An Executor installed on a Linux host or in a Kubernetes cluster reaches out to the Hub for work and reports status back. The blockchain node runs on that customer-controlled infrastructure. The application connects to the node’s RPC route in that environment, not through the Hub.

That arrangement has a useful consequence: if the Hub becomes temporarily unreachable, an existing node can keep running and serving RPC. New management changes have to wait for the connection to return. It does not mean the node is immune to a disk failure, a broken peer connection, a failed RPC gateway or a chain-specific problem. Those are separate dependencies and deserve separate checks.

Test the management connection without breaking the data path

Use a non-production node that resembles the setup you care about. Write down the chain, client versions, runtime, RPC exposure mode and every upstream connection. For an L2 such as Base, include the Ethereum execution RPC and beacon endpoint it reads. Make sure the person running the exercise can restore the management connection quickly.

Before changing anything, establish a baseline. From the same network as the application, send a small, repeatable set of RPC requests and record their response codes and latency. Watch the node’s head advance relative to an independent chain view. Record the latest health report, the process state and the relevant logs. A single successful eth_blockNumber call is too thin; include one or two methods the application actually depends on.

Now isolate only the Executor-to-Hub management connection in the test environment. Do not cut the node’s peer-to-peer path, its L1 inputs or the application’s RPC route as part of the same step. Otherwise a failed request cannot tell you which dependency caused it.

Continue the probes for a defined window while the management connection is unavailable. Keep timestamps for the last Hub report, each RPC response and the chain head observed by the application.

The expected architectural behavior is that existing node processes continue and management actions wait. The measurement shows whether that expectation held for this specific chain, runtime, exposure mode and test window. If an application request fails, investigate the precise path instead of attributing every failure to the control plane.

Reconnect and check the catch-up

Restore the management connection and verify that the Executor reports again. Check whether the node’s actual state matches its desired state, whether any safe test change made during the interruption is applied as expected, and whether the monitoring timeline resumes without hiding the gap. Read the logs and events around both the loss and reconnection.

The gap itself is important. A dashboard that displays the last known block height without its observation time can look reassuring after the data has gone stale. An operator should be able to tell “no fresh report” from “node definitely down.”

At the application edge, direct RPC probes and chain-head checks provide another view while management telemetry is missing.

What the exercise can and cannot prove

If RPC continues answering and the chain head advances during the test, you have evidence that a temporary management outage did not interrupt that node’s serving path under those conditions.

You have not proved that every chain and client combination will behave identically, that the gateway cannot fail, or that the node can run forever without operational changes.

Document the actual observations: the time the connection was cut and restored, which RPC methods were probed, whether the head advanced, any errors, and what happened to management work requested during the interruption. A later test report can say exactly what happened instead of turning an architectural expectation into an uptime guarantee.

Run the exercise before the next incident. Save the network diagram, probe commands, timestamps and rollback owner in the runbook.

When the dashboard is unavailable, the team should still know whether the application can reach a current chain view, and what evidence supports that call.