Production readiness

Launch with credentials you can replace, data you can trust, and failures you can diagnose and recover from. Work through this checklist with your team after your first successful request, then follow your service's usage and troubleshooting pages for protocol-specific decisions.

Six areas to check before production traffic, in the order of this page. Each section below lists the full checklist for its area.

Credentials and access

Create a separate API key for each product, environment, and workload, with a label that names it.
Store keys in a secret manager or server-side runtime configuration.
Keep keys out of logs, analytics events, browser bundles, support messages, and source control.
Confirm each production key belongs to the intended organization and product.
Decide who can rotate and revoke production keys, and test a rotation before launch.

See API keys and the authentication page for your service.

Billing, credits, and limits

Confirm the organization has an active plan or enough credits for launch traffic.
Set low-credit alerts so the right people hear before the balance runs out. At zero or below, requests pause.
Read your service's usage page before choosing concurrency, batch size, or backfill strategy.
Treat entitlement and limit responses as configuration problems; do not retry them indefinitely.

Open billing

Data correctness

Decide how fresh and how stable each result must be, then use the service's tool for it.

Service	Correctness decision
RPC	Anchor multi-request workflows to an explicit block number, hash, `safe`, or `finalized` reference.
Subgraphs	Inspect `_meta` when indexing freshness or indexing errors affect the result.
Substreams	Persist cursors only after committing output, and handle undo signals for reversible data.

Timeouts and retries

Retry only failures that can succeed unchanged, with bounded backoff, jitter and a retry budget. Authentication, entitlement and validation failures need a configuration or request fix first. A Substreams consumer resumes from its last committed cursor instead.

Set explicit connection and request timeouts.
Retry transient failures with bounded exponential backoff and jitter.
Respect server retry guidance when a response supplies it.
Give each workflow a retry budget so a downstream failure cannot create unbounded traffic. Successful retries can count as additional usage.

Observability

Record enough context to diagnose a failed request without recording secrets. One structured entry per failed attempt is enough to answer most support questions:

{  "time": "2026-10-21T14:03:12Z",UTC timestamp  "service": "rpc",GraphOps service  "organization": "acme-production",Organization name or ID  "apiKeyLabel": "production-indexer",Key label, never the key  "endpoint": "/v1/evm/1",Network or endpoint path  "status": 429,HTTP or gRPC status  "error": "Too Many Requests",Safe error detail  "requestId": "<REQUEST_ID>",When the response supplies one  "attempt": 2Retries used from the budget}

An illustrative structured log entry for a failed RPC request. It identifies the organization, key, network and attempt without recording the key itself. Use the same fields for any service.

For Subgraphs, record the Endpoint Alias or Deployment CID and _meta.block.number. For Substreams, record the package, module, and last committed cursor or block when it is safe to share.

Recovery

Define what each client does after a disconnect or partial workflow failure.
Make writes and materialization steps idempotent wherever a retry can repeat work.
Test the troubleshooting path for each service you use.
Decide who contacts GraphOps support and which sanitized details they provide.