Solana Relay Uptime, SLAs & On-Call Support for Production

Solana's throughput and slot timing put unusual pressure on RPC infrastructure. A relay that occasionally lags on Ethereum may be fine for a dashboard, but the same lag on Solana can mean missed slot data, stale account state, or dropped WebSocket subscriptions. If you are evaluating a provider for production traffic, the question is not just "does it work today" but "what happens at 3am when it does not, and who is accountable."

This article focuses on the operational layer: how to read uptime claims, what a Solana RPC SLA should actually cover, how on-call escalation differs between shared and dedicated setups, and how to test any provider before you route real traffic to it.

Production readiness checklist for a Solana relay

Before comparing contracts or marketing pages, decide what your workload actually needs. This checklist helps you separate a shared public endpoint from infrastructure you would depend on for a paid product.

Signal	What to check	Why it changes your choice
Traffic shape	Requests per second, burst patterns, read vs write ratio	Bursty workloads need headroom and rate-limit clarity, not just an average
Method mix	Standard JSON-RPC vs getProgramAccounts, getSignaturesForAddress, large getTransaction calls	Heavy methods behave very differently across providers
Transport	HTTP only, or HTTP plus WebSocket subscriptions	WebSocket stability is a separate operational concern from HTTP
Data freshness	Do you need recent slots, or historical/archive data?	Archive and trace access is often a distinct product tier
Failure tolerance	What happens to your app if the endpoint is unreachable for 30 seconds?	Determines whether you need failover and multi-provider routing
Accountability	Who responds when something breaks, and how fast?	This is where SLAs and on-call support actually matter

If your answers point to "we can tolerate occasional retries and we have no contractual needs," a shared endpoint is fine. If your answers point to "downtime costs money and we need a named escalation path," you are in dedicated node or managed-provider territory.

What "uptime" should mean for a Solana relay

Uptime percentages are easy to print and hard to interpret. A single headline number hides several distinct failure modes:

• Endpoint availability — the HTTP or WebSocket endpoint accepts connections and returns valid JSON-RPC responses.
• Chain freshness — the node is synced to the current slot, not just responding.
• Method-level success — heavy or rate-limited methods succeed, not just getHealth.
• Regional reachability — the endpoint is fast and stable from where your users and servers actually are.

A provider can be "up" by one definition and effectively down by another. When you read an uptime figure, ask what is being measured and from where. A health check that only pings getHealth tells you very little about whether getProgramAccounts will time out under load.

For Solana specifically, freshness matters more than on many chains because slot times are short and applications often depend on near-real-time state. A relay that is technically reachable but several slots behind can break trading logic, indexers, and notification systems without ever triggering a simple availability alert.

Reading a Solana RPC SLA without getting misled

A service-level agreement is a commitment, not a feature list. When you review one, look for these components:

1. Scope — which endpoints, transports, and regions are covered, and which are explicitly excluded.
2. Measurement method — how uptime is calculated, over what window, and from which vantage points.
3. Exclusions — scheduled maintenance, upstream chain issues, and customer-caused failures are commonly excluded. Understand what is left.
4. Remedies — what you actually receive if the target is missed (service credits, escalation, or nothing).
5. Support terms — response times, escalation channels, and whether on-call coverage exists outside business hours.

A useful mental model: an SLA is only as strong as its measurement method and its remedy. A high number with vague measurement and no remedy is a marketing statement. A moderate number with clear measurement, defined exclusions, and a real escalation path is operationally stronger.

If you are running a paid product on Solana, ask the provider directly how they measure availability, whether they publish status history, and what the escalation path looks like during an incident. Providers that can answer these questions concretely are easier to trust than providers that only quote a percentage.

Shared RPC vs dedicated nodes: where support and SLAs differ

The support and accountability model changes significantly depending on which tier you use.

Dimension	Shared/public RPC	Dedicated node
Resource isolation	Shared across many users	Reserved for your workload
Rate limits	Typically pooled and enforced	Sized to your traffic
WebSocket stability	Best-effort under load	More predictable, isolated
Custom methods / archive	Usually limited	Often configurable
Support model	Community or standard support	Named escalation and on-call options
SLA applicability	Rarely contractual	Commonly part of the agreement

This is the core tradeoff behind the query. If you need a contractual uptime commitment and a human who answers during an incident, that usually means dedicated infrastructure or a managed provider tier with a support agreement — not a free public endpoint.

OnFinality offers both shared RPC API access and dedicated nodes, so you can start on a shared endpoint and move to isolated infrastructure as your reliability requirements grow. The right tier depends on your workload, not on a generic recommendation.

How on-call support actually works in practice

"On-call support" can mean very different things. When evaluating a provider, clarify which of these you are getting:

• Business-hours support — a team responds during a defined window, often with a ticketing system.
• Extended-hours coverage — support is reachable outside normal hours, but response times may be longer.
• 24/7 on-call with escalation — a named path from first response to engineering, with defined response targets.
• Dedicated technical contact — a specific person or team familiar with your setup.

For most production Solana applications, the practical questions are: How do I open an incident? What is the first response target? Who gets paged if the first responder cannot resolve it? Is there a status page or incident channel I can watch?

It also helps to know what the provider can and cannot fix. A provider can address endpoint availability, node health, and infrastructure issues. They cannot fix a Solana network-wide congestion event, a bug in your client, or a misconfigured commitment level in your own code. A good support relationship helps you tell the difference quickly.

Testing a Solana relay before you commit

You do not need to wait for an incident to learn how a provider behaves. Run a small, repeatable test against any candidate endpoint before you route production traffic.

Start with a basic health and freshness check over JSON-RPC:

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

Then check a heavier method your app actually uses, and time it:

curl -s -w "\nTotal: %{time_total}s\n" https://solana.api.onfinality.io/public \
  -X POST -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 2,
    "method": "getLatestBlockhash",
    "params": [{"commitment": "confirmed"}]
  }'

For WebSocket-dependent applications, verify subscription stability separately, since HTTP success does not guarantee a healthy subscription channel. A minimal Node.js probe can confirm that slot notifications arrive:

import WebSocket from "ws";

const ws = new WebSocket("wss://solana.api.onfinality.io/public-ws");

ws.on("open", () => {
  ws.send(JSON.stringify({
    jsonrpc: "2.0",
    id: 1,
    method: "slotSubscribe"
  }));
});

ws.on("message", (data) => {
  console.log("slot notification:", data.toString());
});

ws.on("error", (err) => console.error("ws error:", err.message));

Run these probes on a schedule from the same regions your users hit, and log latency and error rates over time. That history is far more useful than any single benchmark, and it gives you a baseline to compare against if you later switch providers.

Monitoring signals worth tracking

Once you are live, a small set of signals will tell you more than a single uptime number:

• Slot lag — the difference between the endpoint's latest slot and the network's current slot.
• Error rate by method — some methods fail more often than others under load.
• p95/p99 latency — averages hide the tail that users actually feel.
• WebSocket reconnect frequency — frequent reconnects often precede visible failures.
• Failover events — how often your client switches endpoints, and why.

If you run multiple endpoints, track these per endpoint so you can see which one is degrading first. This is also the data you will want to bring to a support conversation, because it turns "it feels slow" into a specific, actionable report.

When to move from shared RPC to dedicated infrastructure

There is no single threshold, but these patterns usually signal it is time to move:

• You are hitting rate limits during normal traffic, not just spikes.
• WebSocket disconnects are affecting user-facing features.
• You need archive data, custom methods, or specific node configuration.
• You need a contractual SLA and a defined on-call escalation path.
• Your compliance or internal review process requires documented support terms.

When that happens, review RPC pricing to understand tier differences, and compare supported RPC networks if you operate across more than one chain. For Solana specifically, the Solana network page covers endpoint details and transport support, including HTTP and WebSocket.

Key Takeaways

• Uptime claims are only meaningful when you know what is measured, from where, and over what window.
• A Solana RPC SLA should define scope, measurement, exclusions, remedies, and support terms — not just a percentage.
• On-call support varies widely; clarify response targets, escalation paths, and hours before you depend on them.
• Shared endpoints suit many workloads, but contractual SLAs and named escalation usually require dedicated infrastructure.
• Test any candidate relay with repeatable HTTP and WebSocket probes before routing production traffic.
• Track slot lag, per-method error rates, tail latency, and reconnect frequency as your core reliability signals.

Frequently Asked Questions

Does a higher uptime percentage always mean better reliability?

No. The measurement method matters more than the headline number. An endpoint can be reachable but stale, or fast for light methods but unreliable for heavy ones. Ask how uptime is calculated and which methods and transports are included.

What should a Solana RPC SLA include?

At minimum: the endpoints and regions in scope, how availability is measured, what is excluded (maintenance, upstream chain issues), what remedy applies if the target is missed, and the support and escalation terms.

Is on-call support available on shared RPC plans?

Support models differ by provider and tier. Shared or public endpoints typically come with limited or community support, while dedicated infrastructure and managed plans are more likely to include defined escalation and extended-hours coverage. Confirm the specifics before you commit.

How do I test a Solana relay before using it in production?

Run scheduled JSON-RPC probes for the methods you actually use, measure latency and error rates from your target regions, and test WebSocket subscription stability separately. Keep the results as a baseline for comparison.

When should I move from a shared endpoint to a dedicated Solana node?

Common triggers include persistent rate limiting, WebSocket instability affecting users, a need for archive or custom configuration, and a requirement for a contractual SLA with a named escalation path.

Can a provider guarantee Solana network availability?

No provider controls the Solana network itself. A provider can commit to the availability and health of its own infrastructure and endpoints, and should be clear about what falls outside that scope, such as network-wide congestion events.

Related resources

• Solana RPC network
• Dedicated nodes
• RPC pricing
• How to choose an RPC provider

Originally published at OnFinality.