How do I monitor Solana validator uptime with an API endpoint?

Solana does not publish a single "validator uptime" REST endpoint. If you searched for one, the practical answer is that uptime is a derived metric: you compute it by polling a small set of standard JSON-RPC methods against a Solana RPC endpoint and tracking how a validator's vote and slot activity changes over time. This page covers the exact methods, the request shapes, and the monitoring loop you can run today.

What you can and cannot get from an endpoint

There is no getValidatorUptime method. What Solana exposes is raw chain state that lets you infer liveness:

• getVoteAccounts returns the current and delinquent vote accounts, including lastVote, rootSlot, and epochCredits.
• getSlot and getBlockHeight tell you how far the cluster has progressed.
• getEpochInfo gives the current epoch, slot index, and slot range.
• getBlockProduction reports leader slot production per identity.
• getClusterNodes returns gossip-visible nodes with their versions and features.

Uptime is what you build on top of these. A validator that stops voting, falls behind the cluster slot, or stops appearing in vote accounts is effectively down for monitoring purposes, even if the process is still running.

Decision guide: shared endpoint or dedicated node for monitoring

Before writing polling code, decide what your monitoring loop needs. Validator monitoring is a steady, low-volume, always-on workload, and that changes which endpoint type fits.

If you are checking one validator a few times a day, a shared endpoint is reasonable. If you run alerting that must fire when a validator goes delinquent, a dedicated node removes a class of false positives caused by shared-endpoint contention. OnFinality offers both shared RPC API access and dedicated Solana nodes, so you can start shared and move to dedicated as your monitoring matures.

The methods that actually indicate validator liveness

getVoteAccounts

This is the core call. It returns two arrays: current (voting normally) and delinquent (not voting). Each entry includes the vote account pubkey, the node identity, activatedStake, lastVote, rootSlot, and epochCredits.

curl -s https://solana.api.onfinality.io/public \
  -X POST -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getVoteAccounts",
    "params": [{"votePubkey": "YOUR_VOTE_ACCOUNT"}]
  }'

If your validator appears in delinquent, it has stopped voting. If it is absent from both arrays, the vote account may be new or the request may have failed, so always check the response shape before alerting.

getSlot and getEpochInfo

Compare the validator's lastVote against the current slot. A growing gap means the validator is falling behind. getEpochInfo gives you the slot index within the epoch so you can normalize the gap.

curl -s https://solana.api.onfinality.io/public \
  -X POST -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"getEpochInfo"}'

getBlockProduction

This returns leader slot production. Filtering by identity shows how many slots a validator was expected to produce and how many it actually produced, which is a useful secondary signal alongside vote activity.

Building a polling loop in JavaScript

A minimal monitor polls getVoteAccounts on an interval, records lastVote and epochCredits, and flags a validator when the values stop advancing. The example below uses the OnFinality public Solana endpoint and a WebSocket-free polling approach so it works anywhere.

const RPC = "https://solana.api.onfinality.io/public";
const VOTE_ACCOUNT = "YOUR_VOTE_ACCOUNT";

async function rpc(method, params = []) {
  const res = await fetch(RPC, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({ jsonrpc: "2.0", id: 1, method, params }),
  });
  const json = await res.json();
  if (json.error) throw new Error(json.error.message);
  return json.result;
}

let lastSeenVote = null;
let stalledPolls = 0;

async function poll() {
  const { current, delinquent } = await rpc("getVoteAccounts", [
    { votePubkey: VOTE_ACCOUNT },
  ]);

  const entry = current.find((v) => v.votePubkey === VOTE_ACCOUNT);
  const isDelinquent = delinquent.some((v) => v.votePubkey === VOTE_ACCOUNT);

  if (isDelinquent) {
    console.warn("validator delinquent");
  }

  if (entry) {
    if (lastSeenVote !== null && entry.lastVote === lastSeenVote) {
      stalledPolls += 1;
    } else {
      stalledPolls = 0;
    }
    lastSeenVote = entry.lastVote;
    console.log({ lastVote: entry.lastVote, epochCredits: entry.epochCredits });
  }
}

setInterval(poll, 15000);

Two details matter here. First, epochCredits is an array of [epoch, credits, previousCredits]; the delta between the last two entries is a cleaner liveness signal than lastVote alone. Second, poll on a fixed interval that is comfortably longer than a slot (roughly 400ms) so you are not chasing noise. Fifteen to thirty seconds is a practical default.

Turning raw responses into an uptime number

Uptime is a ratio you define. A common approach:

1. Poll every N seconds and record whether the validator advanced its vote or credits.
2. Count successful advancements as "up" samples and stalled or delinquent states as "down" samples.
3. Divide up samples by total samples over a rolling window (for example, 24 hours).

This gives you a defensible figure that matches your own monitoring cadence rather than an external number you cannot verify. Document the cadence and window alongside the percentage, because the same validator can show different uptime depending on how often you sample.

Endpoint reliability is part of the measurement

If your RPC endpoint drops requests, your monitor records false downtime. That is the single most common source of bad validator uptime data. Guard against it:

• Distinguish transport failures from chain state. A timeout is not the same as a delinquent validator.
• Retry failed requests before counting a down sample.
• Use a second endpoint as a cross-check for alerting decisions.
• Prefer an endpoint with WebSocket support if you later want slot subscriptions instead of polling.

OnFinality's Solana endpoint supports both HTTP and WebSocket transports, so you can poll with JSON-RPC now and add subscriptions later without changing providers. See the Solana network page for connection details.

Chain settings and connection reference

For testing your monitoring code before pointing it at mainnet, use a Solana Devnet endpoint so you do not pollute production metrics with test data.

Common failure modes and how to read them

Key Takeaways

• Solana has no dedicated validator uptime endpoint; uptime is derived from getVoteAccounts, getSlot, getEpochInfo, and getBlockProduction.
• getVoteAccounts is the primary liveness signal, with epochCredits deltas more reliable than lastVote alone.
• Poll on a fixed interval and define your own uptime window so the number is reproducible.
• Endpoint reliability directly affects measured uptime; retries and a second endpoint reduce false downtime.
• A shared endpoint suits occasional checks, while a dedicated node suits continuous alerting.

Frequently Asked Questions

Is there a direct Solana validator uptime API?

No. Solana exposes chain state through JSON-RPC, and uptime is a metric you compute from vote and slot activity over time.

Which method is best for checking if a validator is down?

getVoteAccounts is the most direct. A validator in the delinquent array has stopped voting, which is the clearest down signal.

How often should I poll?

Every 15 to 30 seconds is a practical default. Polling faster than a slot adds noise without improving accuracy.

Can I use WebSockets instead of polling?

Yes. Slot and root subscriptions can replace polling, but you still derive uptime from the same underlying signals. OnFinality's Solana endpoint supports WebSocket transport.

Do I need a dedicated node for validator monitoring?

Only if you run continuous alerting or track many validators. For occasional checks, a shared endpoint is usually sufficient. Compare options on the RPC pricing page and the list of supported RPC networks.