# Out of gas in Ethereum: cause and fix > A transaction that runs out of gas is mined, reverted and still paid. See why the gas limit is the cause, how to spot it, and how to fix it. Source: https://hashspan.dev/errors/out-of-gas ## Short answer Out of gas means the transaction used its whole gas limit before the code finished. The network undoes all of its changes, but the gas is still paid. It shows up as a mined transaction with status reverted and gas used equal to the gas limit. Raise the limit, or find out why the code uses so much. ## What you will see - `out of gas` - `status: reverted, with gas used equal to the gas limit` ## Where does it stop? Figure: A transaction's path from your code to the node, the mempool, a block and a receipt. The block that runs the transaction is marked in red with the error out of gas: it has a hash and a receipt with status reverted. Unlike the refusals at the node, this one happens inside a block. The transaction passed every check, was mined and then ran out of gas while the code was running. It has a hash and a receipt, and the receipt says reverted. ## What is spent, and what is undone? The gas limit is the most you are willing to spend. When the code needs more than that, the EVM stops. [All the changes are reverted, but all the gas provided is still consumed](https://ethereum.org/developers/docs/gas) for the work performed. Figure: A gas limit of 50,000 of which all 50,000 is used. The receipt shows status reverted, gasUsed 50000 and a fee of 88,296,564,050,000 wei. The changes are reverted but the gas is paid, and there is no revert reason to decode. There is no revert reason, because the code never reached a revert: it simply ran out of gas, so there is nothing to decode. ## Why does it happen? - **A gas limit set by hand and too low.** A copied number, or one a model chose in a tool argument. - **A stale estimate.** The estimate was right for the state at that moment. The state changed before the transaction was mined. - **Code that does more work than expected.** A loop over data that has grown. ## How do I fix it? 1. **Estimate instead of guessing,** and add headroom on top of the estimate. See the snippet on the [intrinsic gas page](https://hashspan.dev/errors/intrinsic-gas-too-low#how-do-i-fix-it). 2. **Do not override the limit with a smaller number** than the estimate. 3. **If the estimate is large, find out why.** A loop that grows with data is a bug to fix, not a limit to raise. 4. **In a worker or an agent, record the limit with the transaction,** so a receipt with gas used equal to the limit is easy to spot. ## What does it look like in a trace? The `send` span is fine: the transaction was accepted and has a hash. The `confirm` span ends with an error, because the receipt says reverted: No revert reason on a reverted confirm span, and gas used equal to the limit you sent, point to out of gas. A reverted span that does have a reason is [execution reverted](https://hashspan.dev/errors/execution-reverted). How the status is set is in [span status](https://hashspan.dev/learn/otel-span-status). ## FAQ ### Do I pay for a transaction that ran out of gas? Yes. If a transaction runs out of gas during execution, the EVM reverts any changes, but all the gas provided is still consumed for the work performed (ethereum.org, Gas). In our run the fee was 88,296,564,050,000 wei for 50,000 gas. ### How do I tell out of gas from a revert? Compare gas used with the limit you sent. When they are equal and there is no revert reason, the code ran out of gas. A revert with a reason, such as a failed require, uses part of the limit, and hashspan can decode its reason. In our run a revert used 21,054 gas of a 100,000 limit. ### Why did the estimate not prevent it? An estimate is made against the state at that moment. If the state changes before the transaction is mined, or you override the limit with a smaller number, the work can need more gas than you allowed.