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

📘

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:

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:

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.