Status and Metrics

A green status page is useful, but it is not the same thing as production observability. For a Solana app, the better question is: can you tell whether a bad user moment came from normal traffic growth, a burst that crossed your plan limit, a client retry loop, or a real service incident?

Use this page as the operational map for Carbium RPC signals. It points you to the right live surface, then shows which metric answers which support question.

Part of the Carbium Solana infrastructure stack.

---

Where to look first

What you need to know	Start here	What it tells you
Account, plan, billing cycle, and remaining credits	RPC Dashboard	Whether the account is configured and has usage budget available
Method-level RPC usage and credit consumption	Calls Monitoring	Which methods, jobs, or traffic patterns are consuming requests
Whether a failure is auth, throttling, JSON-RPC, or transaction related	RPC Errors Reference	How to classify the failure before retrying or escalating
Whether burst traffic is exceeding plan throughput	Solana RPC Rate Limits Explained	Why 429 happens and how to shape traffic safely

📘 Do not wait for a launch or incident to open these pages for the first time. Capture a normal baseline while the application is healthy so spikes and regressions are easier to recognize later.

---

The signals that matter in production

Credit burn

Credit usage tells you how much total RPC work your account is doing over time. Watch it when:

• monthly usage is climbing faster than expected
• test, staging, and production traffic share the same account
• a background job might be running more often than intended
• a new feature adds balance, account, transaction, or token metadata reads

Credit burn is a budget and capacity signal. It does not by itself prove that the endpoint is unhealthy.

Request bursts

Requests-per-second pressure tells you whether your client is sending too much traffic at once. This is the signal to inspect when you see 429 Too Many Requests, especially during:

• user-facing launches
• cron jobs that start on the same minute
• bot or monitoring workers restarting together
• retry storms after a timeout
• dashboards or wallets polling too aggressively

The fix is often traffic shaping before plan changes: backoff, jitter, queues, caching, and separating noisy jobs from latency-sensitive paths.

Method mix

Method mix shows whether your application is using the RPC surface the way you expected. A few examples:

Pattern	What it can mean	First response
getBalance or token-account reads spike	Wallet or dashboard polling increased	Add caching or reduce polling frequency
getTransaction grows sharply	Confirmation, indexing, or support lookup paths expanded	Check whether a streaming or batched path fits better
sendTransaction retries cluster	The write path may be retrying before status checks	Check signature status before resending
Health checks dominate traffic	Monitoring is too chatty	Slow the interval or consolidate probes

Method mix is where many "provider problem" reports turn into client-side tuning work.

---

A practical incident read

When something feels wrong, avoid jumping straight to "RPC is down". Read the signals in this order:

1. Check the raw error: HTTP status, JSON-RPC error code, method, and request time.
2. Check dashboard state: active plan, remaining credits, and account access.
3. Check usage: which method changed, whether the spike is isolated, and whether retries amplified it.
4. Check rate-limit behavior: if the failure is 429, reduce pressure before widening retries.
5. Check transaction state: for writes, verify signature status before sending another transaction.

This sequence keeps the first response grounded in evidence instead of guesses.

type RpcLogLine = {
  at: string;
  method: string;
  httpStatus: number;
  rpcErrorCode?: number;
  requestId: string;
  durationMs: number;
  attempt: number;
};

function shouldEscalate(line: RpcLogLine) {
  return line.httpStatus >= 500 || line.rpcErrorCode === -32603;
}

The exact logging shape is up to your stack. The important part is preserving enough context to connect a user report to a request, a method, and a time window in the dashboard.

---

What each page should own

This page is the map. Use the deeper pages when you need the full procedure:

Need	Canonical owner
Full tier choice, credits, RPS caps, and gRPC plan threshold	RPC Pricing and Usage Tiers
429 behavior, backoff, and burst mitigation	Solana RPC Rate Limits Explained
HTTP status, JSON-RPC error code, preflight, and support payload triage	RPC Errors Reference
API key handling, endpoint restrictions, and rotation	API Key Security Best Practices
Account-level dashboard orientation	RPC Dashboard
Method-level usage view	Calls Monitoring

---

Baseline checklist

Before production traffic ramps, capture these normal values:

• expected daily credit burn
• normal peak request window
• most common RPC methods
• normal error rate by method
• retry count distribution
• separate labels for dev, staging, and production traffic if your stack supports them
• current plan and whether the workload depends on gRPC

🔶 Need production Solana RPC with usage visibility and plan headroom? Start with Carbium at carbium.io, then use the dashboard and monitoring pages to keep the workload observable.