If you're running a Solana application in production, monitoring is what tells you whether things are actually working. Most teams under-monitor on the RPC side specifically — they watch their app's user-facing metrics but don't have visibility into the RPC layer that determines whether transactions actually land. This piece covers what to track, why, and the dashboards that turn opaque RPC behaviour into actionable visibility.
What "RPC Monitoring" Actually Means
Three categories of monitoring:
Server-side metrics from your provider. RPC providers should expose latency dashboards, error rates, capacity. Quality varies by provider.
Client-side metrics from your application. What your app sees when calling the RPC. P50/P95/P99 latency, error rates, retry rates.
Outcome-side metrics. Did transactions actually land? At what prices? What was the cost?
For production observability, you want all three. Provider-side tells you about their capacity; client-side tells you what you're experiencing; outcome-side tells you whether your application is actually working.
Metrics That Matter
Latency percentiles. Not averages. P50, P95, P99 of round-trip latency for RPC calls. Tracked over time.
Error rates. What percentage of RPC calls fail? Broken down by error type.
Retry rates. How often is your code retrying? High retry rates suggest underlying issues.
Submission success rate. How many sendTransaction calls return a signature without error?
Landing rate. How many submitted transactions actually land on-chain (different from "submission succeeded").
Tail latency under load. P99 latency during peak hours. Compare to off-peak.
Cost per landed transaction. Total fees + tips ÷ successful sends.
Sandwich exposure. For trading workloads. AMM-math expected vs actual fills.
Connection pool stats. For high-volume code. Pool size, in-use connections, wait time.
What to Track Per Transaction
For every transaction submitted, log:
- Timestamp
- Signature
- Compute budget set
- Priority fee set
- Blockhash used
- Submission latency (HTTP round-trip)
- Confirmation outcome (landed, failed, expired)
- Confirmation latency (signature to landed)
- Slot of inclusion
- Fees paid (CU consumed × CU price + base)
- Tips paid (Jito or other)
- Slippage tolerance set
- Actual output received (for swaps)
- Expected output (for swaps)
- Error code if failed
This is per-signature telemetry. Without it, you can't debug specific failures or analyse aggregate performance.
Building the Telemetry
A reasonable schema (in TypeScript):
interface TxTelemetry {
signature: string;
submittedAt: number;
landedAt?: number;
outcome: 'pending' | 'landed' | 'failed' | 'expired';
errorCode?: string;
cuLimit: number;
cuPrice: number;
tipLamports?: number;
blockhash: string;
slot?: number;
feesPaid?: number;
intent: 'swap' | 'transfer' | 'mint' | string;
expectedOutput?: number;
actualOutput?: number;
}
Persist to a database or log aggregator (Datadog, Honeycomb, ELK, custom). Retain at least 30 days for trend analysis.
For high-volume bots, you may sample (log 1% of transactions in full detail; aggregate the rest). For low-volume apps, log everything.
Dashboards That Are Useful
A small set of dashboards covers most needs:
Latency dashboard. P50/P95/P99 of submission and confirmation latency. Trend over time. Per-RPC if you use multiple.
Error breakdown. Failures categorised by type. Spikes in specific error types signal environmental issues.
Cost dashboard. Fees + tips per landed transaction. Trend over time. Compare to revenue (for trading workloads).
Sandwich exposure dashboard (for trading). Average gap between expected and actual fills. Trend.
Capacity dashboard. Connection pool utilisation, requests per second, retry rates. Tells you if you're hitting limits.
Outcome funnel. Submitted → Accepted by RPC → Landed → Profitable (for trading). Where do transactions drop out?
Alerting
What's worth alerting on:
P95 latency > threshold. Specific to your workload. For HFT, sub-second; for general apps, a few seconds.
Error rate spike. Sudden increase in any specific error category.
Landing rate drop. Sudden decrease in successful landings.
Sandwich exposure spike. For trading; sudden increase in expected-vs-actual gap.
Cost spike. Total cost per period exceeding expected.
Provider issues. From provider-side status pages or your own probes.
Specific custom anomalies. Each app has unique conditions worth alerting on.
Don't alert on everything. Alert on conditions where someone needs to wake up. Everything else goes to dashboards.
Common Monitoring Mistakes
Monitoring averages instead of percentiles. Average latency tells you nothing about production behaviour.
Monitoring only success. What goes wrong is more informative than what goes right.
Polling instead of pushing. Pulling logs into a dashboard is slow; push from your application.
No alerting plan. You collect metrics but no one looks at them until something breaks.
Alerting on too much. Cry-wolf alerts get ignored.
Not retaining history. Without 30+ days, you can't analyse trends or compare to baselines.
No per-signature granularity. Aggregate metrics tell you something is wrong; per-signature tells you what.
What to Do This Week
If you're improving monitoring:
- Start with per-signature telemetry. This is the foundation; everything else aggregates from it.
- Build the latency dashboard. P50/P95/P99 over time.
- Build the error breakdown. Categorised failure rates.
- Set up basic alerting. P95 latency, error rate spike, landing rate drop.
- Look at the data. Trends, baselines, anomalies. The data is only useful if you actually look.
- Document what "normal" looks like. So you can recognise abnormal.
- Iterate. Add metrics as you learn what matters.
What BoltTx Provides
BoltTx exposes monitoring data on its side:
- Per-signature delivery telemetry — for each transaction, when each step happened
- Latency dashboards — P50/P95/P99 over time
- Error breakdown — what failed and why
- Per-customer isolation so your metrics aren't polluted by others' traffic
import { Connection } from "@solana/web3.js";
const connection = new Connection(
"https://bolttx.io/?api-key=YOUR_API_KEY",
"processed"
);
You combine BoltTx's provider-side data with your application-side telemetry for full observability. Free tier signup — telemetry available on free tier.
FAQ
What's the minimum monitoring setup? Per-signature telemetry + latency dashboard + basic alerts (P95 latency, error rate). Anything less and you can't operate production.
How long should I retain data? 30 days minimum for trend analysis. Longer if you need to debug recurring issues.
Should I build my own dashboards or use a SaaS? SaaS (Datadog, Honeycomb, Grafana Cloud) for most teams. Roll your own only at significant scale.
What's a normal P95 latency for Solana RPC? Depends on workload and RPC. Sub-second is achievable for transaction sending. Read latency varies more.
How do I know if I'm being sandwiched? Compare AMM-math expected output to actual output for swaps. Systematic gap = sandwich exposure.