Why gas tracker lies: bottlenecks in gas monitoring
Almost every gas tracker is assembled from whatever is at hand: a public node, a few aggregators, cache on the service side. While the network is calm, sources produce similar numbers, and the gas monitoring system looks accurate. The difference shows up during a spike — that is when data divergence becomes noticeable.
First cause — update delay. While one node has not yet seen the stream of pending transactions, another has already recalculated its estimate, and on adjacent screens the transaction cost differs by several times. The user sees not the market, but the difference in source polling speed.
Second — cache. A long record lifetime saves calls to nodes, but during activity it returns a price calculated several blocks ago. The transaction goes out either overpaying or sits in the queue until the base fee rolls back.
Third — collapsing the fee into one number: after networks moved to an auction with a base part and tips, the total depends on both components, and a tracker that shows only "gas price" does not explain why, with the same value, a transaction confirms either in the next block or an hour later.
Another layer — accounting only for the estimate, without checking against actual inclusion of transactions in blocks and without handling chain reorganizations. Because of this, the number on the dashboard and actual spend diverge systematically, not occasionally. Let's break down how this is closed in production gas monitoring.
What changes after implementation: speed, accuracy, resilience
Gas estimation accuracy stops being a constant with a buffer.
The calculation is based on the base fee of recent blocks, the distribution of priority tips, and the load profile of the pending transaction pool — the proposal is assembled for a specific scenario (transfer, contract call, mass payout), rather than by a single multiplier for everything.
Reaction time is counted not from the moment an operation gets stuck, but from a jump in network cost.
Threshold rules on base fee and pool depth send an alert to the on-call channel within seconds, and some scenarios are closed without a human: by raising the priority tip or moving the queue to a calm window.
Along with this, the share of rejected transactions falls.
A class of failures related to incorrect fee estimation and a stale price at the moment of signing goes away: the request is rebuilt before sending, the queue is ordered by sequence numbers, retry happens with a new calculation, not with a copy of the previous signature.
Cost forecasting provides a forward window, not a "right now" snapshot. It is used to plan mass operations and payouts: the queue moves into calm intervals, not into the peak, and execution cost stops depending on who pressed the button at the right moment.
Service resilience is a consequence of the design, not a promise. Multiple independent RPC sources, node lag monitoring, buffering alerts when the channel is unavailable, and redelivery without losing events.
Failure of one source does not turn into a blind spot, and degradation is visible in metrics before it shows up in complaints.
Methods of collecting gas data: comparison of approaches
Gas forecast accuracy is determined not by the formula but by data sources: the base fee is recalculated every block, while the priority fee depends on competition in the mempool.
One source gives a snapshot at the time of request and does not show dynamics — it cannot distinguish a one-off spike from sustained growth.
The difference between approaches lies in latency, completeness, and support cost, and that is what determines what you can show in the interface.
| Option | When it fits | Limitations |
|---|---|---|
| Polling public nodes | Quick start, one or two regions | Request limits, discrepancies between providers, no history |
| Own node | Full block history and control over polling frequency are needed | Synchronization, disk volume, client updates |
| Ready-made gas API Etherscan | Prototype and infrequent requests | Single source, delay between updates |
| Own metrics aggregator | Complete picture, resilience to source failure | Data normalization is needed, more expensive to support |
In practice, we combine at least three sources and consolidate them in a metrics aggregator: divergence between them is itself a signal of network overload, noticeable earlier than the absolute price value.
If one source goes down, the forecast continues to be built from the others, and the tracker does not "go blind."
Polling frequency is configured separately for base and priority fees: infrequent polling gives a smooth graph for analytics and history, frequent polling gives reaction to spikes at the moment a transaction is sent.
Development stages: from source audit to handover
Developing a gas tracker is not a single script but a sequence of engineering work where an error at the beginning costs the most: an incorrect data collection scheme only becomes apparent under load, when rebuilding is more expensive than designing from scratch.
That is why implementation stages go from source audit to system handover, and each stage ends with a verifiable artifact.
-
Source audit. We compile a list of network nodes, block explorers, and external data providers, and compare their readings for base and priority fees over the same period.
A discrepancy of a few percent means different averaging methodologies — we fix one, otherwise alerts will start contradicting each other.
-
Data collection scheme. We determine what we capture: every block or only problematic ones, and whether the pending transaction stream is separate. We design redundancy — if the primary node fails, switching is automatic, without missed blocks or gaps in history.
-
Storage and alerts. We configure time-series storage with archive depth and thresholds: base fee above a specified value for longer than N minutes, a spike in the pending queue, abnormal gas consumption in a block. Notifications go to a messenger, a callback address, and the monitoring dashboard.
-
Load testing. We run the system on a real block stream, including activity spikes and chain reorganization. We look at the delay from transaction appearance to notification, history completeness, and behavior when one of the sources is unavailable.
-
System handover. We deploy it in your infrastructure, provide configurations, the data schema, threshold descriptions, and a manual. We train the on-call team so thresholds and alert routes can be changed without us.
Handover artifacts: schemes, configurations, regulations
After delivery, the customer retains not only working gas monitoring but also a set of documents the team can use to develop and support the system without us. Below is what is included in the handover and the criteria by which it is accepted.
- System documentation: a data flow diagram from polling network nodes to writing to storage and sending an alert, with a list of failure points and actions for each.
- Service configurations: configuration files for the collector, aggregator, storage, and dashboard with an explanation of each parameter, default values, and boundaries beyond which system behavior changes.
- Alert rules: an "event — threshold — channel — recipient" matrix with trigger conditions, repeat suppression, and escalation procedure if the on-call person does not respond.
- Access policies: roles and permissions in the dashboard, keys to network nodes and external sources, their rotation and revocation procedure, and separation of access between the on-call shift and development.
- Operations regulations: frequency of routine work, component update procedure, data liveness checks, actions during degradation, and rollback to the previous configuration.
- On-call instructions: short scenarios for common incidents — missing data, growing delays, false alert.
- Deployment and backup scheme: what data is saved and how often, how the environment is brought up from scratch, and how long it takes.
Acceptance is done for each item separately: we show the document, and your team checks it against their own tasks.
Case study: how the tracker stopped diverging from network data
Before: manual reconciliation
A team that handled gas calculations for a wallet with several thousand active users kept the cost manually: an on-call person every 15 minutes compared the base rate in the public explorer Etherscan and adjusted the tip in the settings.
While the network was calm, the scheme held up, but during spikes transactions hung waiting for 20-40 minutes.
The forecast diverged from the actual effective price by more than 20% in roughly every eighth send, and 6-9 transactions per day failed due to insufficient tip. The user saw "sent," then "stuck," then paid again.
After: automatic collection
We assembled an automatic collection loop: subscription to new blocks and the pending transaction stream, calculation of the base rate and tip distribution over recent blocks, short-lived cache, and recalculation on every block.
The forecast is provided to services together with a confidence estimate, and divergence from the actual value is written to a metric.
The share of sends with divergence above 20% fell to one in sixty, forecast update latency — from 15 minutes to 3-5 seconds, and the share of failed sends — from 7% to 0.4%.
The on-call person reviews warnings instead of making manual edits: the system raises the tip on its own during overload and switches to a backup node if the provider returns stale data.
Automatic control became part of reliability: a warning arrives when divergence persists for several blocks in a row. Failures that a user previously found in the wallet are now caught by monitoring.
How is a gas tracker different from a block explorer?
A block explorer answers the question "what has already happened": it shows blocks, transactions, and the fee actually paid, but only after the operation is included in the chain.
That is not enough for planning — by the time the number appears in the list, the price decision has already been made.
A gas monitoring system works one step earlier, before the transaction is signed. It calculates the base and priority fee, estimates at what price the operation will get into one of the nearest blocks, and keeps the forecast up to date.
The wallet or service backend receives a ready value and inserts it into the price field instead of guessing.
The difference between the tools is especially visible in cost history.
A one-off price request is useless if the operation is not urgent: the aggregator accumulates data and shows load windows — when the network is calm and the fee stays low, and when it steadily gets more expensive.
From this history, you can see at what hours it is more profitable to launch batch operations: payouts, mint, rebalancing.
A separate layer is peak warning. Rules track a sharp rise in the base fee and notify before the service sends a batch of transactions at an inflated price.
The threshold, averaging window, and notification method are configured, so the engineer gets a signal in advance instead of dealing with the consequences of overpayment.
Bottom line: a block explorer is an archive and ledger of facts, a gas tracker is a tool for deciding on price. The first shows what happened; the second shows how much an operation will cost and when it is profitable to send it.
Common technical questions about gas monitoring
At the evaluation stage, questions concern not the interface but the data: where the gas price comes from, what happens to it during overload, and how the tracker behaves when a node fails. Below are answers to engineering concerns that most often come up before work starts.
How accurate is the data during network overload?
We calculate the median over recent blocks, not the one-minute average: the base fee and priority tip are recalculated every block, so the forecast is not smoothed during peak hours.
How is a new network connected?
The network is described by configuration: chain ID, node addresses, fee calculation scheme. We test the addition on historical blocks — no core changes are required.
What to do with an already deployed metrics collection setup?
The tracker connects as another source to the existing metrics storage via a standard interface. Graphs and alerts remain, supplemented with gas metrics.
What if the source node is unavailable?
Polling runs in parallel through several independent node providers, and readings are compared with each other. If there is divergence or stream interruption, the data is marked as unreliable and goes to backup, rather than sticking at the last value.
Is access to wallets needed?
No: public data on blocks and the transaction queue is enough; keys remain with the customer. Access is needed only for automatically sending transactions — this is a separate service with limited permissions.
Let's discuss the task: what data to send for an estimate
Estimating a gas tracker project does not hinge on the volume of code but on the clarity of the current picture: where the service already collects gas data and where the metric lives in the on-call person's head.
The more precise the inputs, the fewer assumptions in the work plan and the faster we can state timelines and stage composition.
What to send so the estimate is substantive:
- List of networks and their roles: mainnet, test environments, Layer 2 networks — where gas monitoring is needed and where it is currently not covered.
- Current gas data sources: own node, public access points, or external service — and which of them is considered the source of truth in case of divergence.
- Current metrics collection: what is already being written — base rate, priority tip, block fullness, transaction count — in what form it is stored and how far back history is available.
- Critical divergences: which cases you consider a failure — a missed peak, divergence between source and on-chain confirmation, alert delay by several blocks.
- Internal loop: where alerts should go (monitoring dashboard, incident system, chat), who the recipient is, and what action is expected after triggering.
- Volumes and frequency: how many transactions per day go through the service, whether history analysis is needed or a sliding window of recent blocks is enough.
- Access restrictions: permitted deployment perimeter, closed segments, requirements for key and log storage.
- Existing work: your own scripts, alert rules, data schemas — so we do not rewrite what already works.
With this set, we come back with an estimate and plan: stage composition, checkpoints on real traffic, data schema, and the procedure for bringing it into production. Describe the task — we will clarify what is missing and propose a work plan.