How to Debug a Stuck Ethereum Transaction Using RPC

24 October 2026

A stuck Ethereum transaction is one that has been submitted to the network but remains unconfirmed for an unusually long time. You can debug it by querying your nodes/rpc-endpoint-basics/">RPC endpoint for the transaction's current state, checking its nonce, gas price, and mempool status, then taking corrective action like replacing or cancelling it. This page walks through the specific RPC calls and what their responses tell you.

What "Stuck" Actually Means on Ethereum

An Ethereum transaction is "pending" until a miner includes it in a block. If it stays pending for hours or days, something is wrong. Common causes:

• Gas price too low - The network's base fee plus your priority fee is below what miners will accept.
• Nonce gap - You submitted a transaction with a nonce that is not the next one in your account's sequence. The network will not confirm it until the earlier nonces are mined.
• Mempool congestion - The network is busy, and your transaction is competing with thousands of others.
• Node rejection - Your RPC provider's node may have dropped your transaction from its local mempool.

Step 1: Get the Transaction Receipt

Start by calling eth_getTransactionReceipt with the transaction hash.

{
 "jsonrpc": "2.0",
 "method": "eth_getTransactionReceipt",
 "params": ["0xYOUR_TX_HASH"],
 "id": 1
}

• If the response includes a blockNumber, the transaction is confirmed. It is not stuck.
• If the response is null, the transaction has not been included in any block yet. Proceed to Step 2.

Step 2: Get the Full Transaction Object

Call eth_getTransactionByHash with the same hash.

{
 "jsonrpc": "2.0",
 "method": "eth_getTransactionByHash",
 "params": ["0xYOUR_TX_HASH"],
 "id": 1
}

A successful response returns an object like this:

{
 "blockNumber": null,
 "nonce": "0x5",
 "gasPrice": "0x3b9aca00",
 "gas": "0x5208",
 "from": "0x...",
 "to": "0x..."
}

Key fields to inspect:

• blockNumber being null confirms it is still pending.
• nonce - This is the transaction's position in your account's sequence. If this nonce is not the next one your account expects, you have a nonce gap.
• gasPrice or maxFeePerGas/maxPriorityFeePerGas - Compare this to the current network conditions.

Step 3: check your account's current nonce

Call eth_getTransactionCount with your address and the parameter "pending".

{
 "jsonrpc": "2.0",
 "method": "eth_getTransactionCount",
 "params": ["0xYOUR_ADDRESS", "pending"],
 "id": 1
}

The result is a hex number. Convert it to decimal. This is the next nonce your account expects.

• If the nonce of your stuck transaction is lower than this number, there are pending transactions with lower nonces ahead of it. You need to resolve those first.
• If the nonce of your stuck transaction is equal to or higher than this number, there is no nonce gap. The problem is likely gas price.

Step 4: check current network gas prices

Call eth_gasPrice to get the current base fee plus priority fee the node recommends.

{
 "jsonrpc": "2.0",
 "method": "eth_gasPrice",
 "params": [],
 "id": 1
}

For EIP-1559 transactions, also call eth_feeHistory to see recent priority fees and base fees. A typical request:

{
 "jsonrpc": "2.0",
 "method": "eth_feeHistory",
 "params": ["0x4", "latest", [25, 50, 75]],
 "id": 1
}

The response shows the 25th, 50th, and 75th percentile priority fees for recent blocks. If your transaction's priority fee is below the 25th percentile, it is unlikely to be included soon.

Step 5: Check Mempool Status (Advanced)

Some RPC providers expose txpool_content or txpool_inspect if they run a full node with the txpool API enabled. Public RPC endpoints almost never allow this. If you are running your own node, call:

{
 "jsonrpc": "2.0",
 "method": "txpool_content",
 "params": [],
 "id": 1
}

This returns all pending and queued transactions the node knows about. If your transaction is not in the pending dict but is in the queued dict, it means the node sees a nonce gap. If it is missing entirely, your RPC provider may have dropped it.

What to do after debugging

Once you know the cause, you have three options:

1. Replace (speed up) - Send a new transaction with the same nonce, same from address, same to and data, but a higher gas price. The network will replace the old one if the new gas price is at least 10% higher.
2. Cancel - Send a transaction with the same nonce, same from address, to = your own address, value = 0, and a higher gas price. This effectively cancels the stuck transaction.
3. Wait - If gas prices drop, your transaction may eventually confirm. This can take days during network congestion.

Common Pitfalls

• Nonce mismatch across RPC providers - Different nodes may see different pending nonces if your transaction was broadcast to only one provider. Check with the provider you submitted through.
• Transaction dropped from mempool - Some providers expire pending transactions after a few hours. If eth_getTransactionByHash returns null but eth_getTransactionCount shows the nonce is still pending, your transaction may have been dropped. You must resubmit with the same nonce and higher gas.
• Sending to a contract that reverts - A transaction that reverts can still be mined, but if the gas price is too low, miners may ignore it because they know it will fail and waste block space.

When to run your own node

If you frequently debug stuck transactions, consider running your own execution client (see our page on Geth vs Erigon). A self-hosted node gives you full access to txpool methods, allows you to control mempool expiry, and removes reliance on a third party's policy for dropping transactions. You also avoid rate limits that can slow down debugging.

Back to rpc & nodes