Start with why it broke
Iteradian records every proxied call with its method, network, status code, latency and client IP, and aggregates usage, error and throttle counts per organization, API key, network and RPC method, per day. Root Cause Analysis groups failures into their likely cause so an error spike resolves to a reason rather than a number. Where a metric has no data behind it, the dashboard shows an empty series and says so.
Verified against the metering and dashboard code on .
If we don’t have the data, the chart says so
Most dashboards will draw something whatever you give them, and a plausible shape with nothing behind it is indistinguishable from a real one. Iteradian’s charts are built from recorded requests and recorded node health. Where there is no data for a window, you get an empty series and a note explaining why — not a smoothed line, not a placeholder, not noise. It makes some screens look emptier. It also means that when a chart does show something, it happened.
Root Cause Analysis
When your error rate moves, the useful question is which of your calls broke and why. Root Cause Analysis clusters recorded failures by what they have in common — the method, the network, the status, the node that served them — so an incident arrives as a reason rather than a red line on a chart you then have to investigate by hand.
Request log explorer
Every proxied call is written with its method, network, status code, latency, region and client IP, and is filterable and searchable. This reflects real traffic: the viewer reads the table the gateway writes on the request path, so what you see is what was actually served.
Usage by key, network and region
Requests over time, broken down by API key, network and region, with a daily table. Together with the request log, filtered by method, it turns "our bill went up" into "eth_getLogs tripled on Base last Tuesday", which is a question you can act on.
Average and P95 latency
Percentiles are computed from your own recorded requests, so you can tell a slow client loop apart from a slow chain. These are your numbers about your traffic — Iteradian does not publish them as a benchmark, and you should not read them as one.
Alert rules and channels
Rules can be attached to your own metrics, with delivery by email, webhook or Slack. Channel secrets are encrypted at rest. Throttled requests are recorded like any other outcome, so hitting a plan ceiling is something you can alert on rather than something you discover later.
Honest empty states
Where a metric has no real data behind it, the chart shows an empty series with an explanation instead of inventing a shape. The failover timeline is the clearest case: it derives from recorded node health checks, and when there is no health data for the window it returns nothing rather than a plausible history.
Analytics FAQ
Where does the analytics data come from?
From the gateway itself. Every proxied request is recorded on the request path — success, JSON-RPC error and throttled rejection alike — and that record feeds both the daily usage aggregates and the request log explorer. Nothing on the dashboard is sampled from somewhere else or reconstructed after the fact.
Are throttled requests visible?
Yes. A request rejected for the per-second rate, the concurrency ceiling or the monthly allowance is recorded with its 429 status and a throttle flag before the error is returned. Hitting a limit is something you can see in usage and in the log, not something you have to infer from missing traffic.
What does "if we don't have the data, the chart says so" mean in practice?
It means an empty series and an explanation, rather than a line. The failover timeline is derived from recorded node health checks for the networks you actually used; with no health data for the period it reports nothing. A dashboard that draws plausible noise when it has no data is worse than one that draws nothing, because you cannot tell the two cases apart.
Does Iteradian publish latency benchmarks?
No. The dashboard shows you percentiles for your own traffic, which is a different thing from a published measurement. Iteradian does not publish a latency benchmark or an uptime percentage anywhere on this site, because there is no measurement behind either that we could point you at.
How long is request history kept?
Daily usage aggregates are retained per organization, API key, network and method. Individual request log entries are retained for 30 days. Contact us if you need a specific retention period before purchase.