Failed Transaction Alerts

How it works

1. Every block is read. Chainitor reads each new block of the chain once and picks out the transactions sent from or to your address, depending on the direction you choose: outgoing, incoming, or both.
2. Each candidate's receipt is checked. A transaction whose receipt has status 0 reverted. For those, Chainitor replays the call to read the revert message, when the node provides one, and records the gas used.
3. Your check interval decides when you hear about it. At each check (every minute at the fastest on Pro), the monitor looks at the failures found since the last check. If there is at least one, it turns critical and alerts you with the latest transaction hash and revert reason.
4. Recovery is reported too. When a check finds no new failures, the monitor returns to healthy and sends a recovery notice, so a channel shows when the problem stopped as well as when it started.

What you configure

• Chain: Ethereum, Polygon, Arbitrum, Optimism, BNB Chain, Base, Robinhood Chain, or the Ethereum Sepolia, Polygon Amoy, BSC testnet, Arbitrum Sepolia, Optimism Sepolia and Base Sepolia testnets.
• Address: a wallet (EOA) or a contract.
• Direction: transactions sent from the address, sent to it, or both.
• Contract interactions and deployments: included by default. Unticking only skips contract-creation (deployment) transactions; calls to contracts are still checked.
• Check interval and alert channels: email, Slack, Telegram, PagerDuty and webhook are on every plan.

Example configurations

Why transactions fail, and what the alert tells you

The revert reason usually points straight at the cause. Common ones for automated senders:

• Slippage or price checks: a swap whose minimum output was no longer reachable by the time it was mined.
• Insufficient balance or allowance: "transfer amount exceeds balance" or "insufficient allowance" from a token contract.
• Access control: a role was revoked or a contract was paused, and every call now reverts.
• Out of gas: a gas limit estimated too low for the path the call actually took.
• Stale state: a keeper calling a job that another keeper already performed.

A wallet that has run out of its gas token cannot get a transaction on chain at all, so nothing reverts and this monitor stays quiet. Pair it with a low gas balance alert to cover that case.

Limits worth knowing

• It watches transactions whose sender or recipient is your address. A failed internal call inside a transaction that itself succeeded is not a failed transaction and is not reported.
• Revert reasons depend on the node replaying the call. Custom errors and bare reverts may show as "Transaction reverted".
• Alerts arrive at your next check after the block is read, not instantly at block time.

Frequently asked questions