Skip to main content
Tenderly applies three kinds of limits, and each one returns a different error:
  • A monthly usage limit caps how much of a product the organization uses in a calendar month.
  • A per-second rate limit caps how fast a single Node RPC accepts requests.
  • A Virtual Environment write limit caps the write operations one Virtual Environment accepts over its lifetime, on plans that include it.
They are independent. A Node RPC can be rate-limited while the organization has used a fraction of its monthly limit, and a Virtual Environment can reach its write limit while the Usage page shows low usage. Features or networks the plan doesn’t include return other errors, covered in Plan features and restrictions.

​
Identify the limit from the error

​
Monthly usage limits

Each product the plan includes has a monthly limit: Simulations and Monitoring count requests and scanned transactions, and Node RPC counts Tenderly Units (TUs). The Billing page lists the limits and the Usage page shows how much of each is used. Usage counts from the first day of each calendar month and resets at the start of the next month, not on the subscription’s renewal date. What happens when usage passes the limit depends on the plan:
  • Soft limits: requests keep working, and usage above the limit is tracked as overage. A Node RPC’s Settings show Soft limited under Limits, and its Overview shows Soft limits enabled.
  • Hard limits: once usage passes the limit, requests are rejected with HTTP 403 and JSON-RPC error -32004 until the limit resets or the plan changes. A Node RPC’s Settings show Hard limited under Limits.
From 80% of a monthly limit, project pages show a banner with the percentage used. To raise a limit or change how it’s enforced, contact our sales team.
Requests sent with a leaked access key count toward the organization’s usage. If a key leaks, reset it right away: on a Node RPC, open Settings and click Reset Access Key; for API tokens, revoke the token.

​
Per-second rate limits

Each Node RPC has a per-second rate limit measured in TUs. Because the limit counts TUs rather than requests, a few expensive calls reach it sooner than many cheap ones. A request over the limit gets HTTP 429:
Rate-limited requests consume no TUs and don’t count toward the monthly limit. Retry them with an exponential backoff, and spread expensive calls such as simulations over time. To find which methods were rate-limited and when, see Investigate rate limiting. To discuss rate limits for your Node RPCs, contact our sales team.

​
Virtual Environment write limits

On plans that include it, each Virtual Environment accepts a fixed number of write operations over its lifetime. Write operations are RPC calls that change the environment’s state:
  • Sending transactions: eth_sendTransaction, eth_sendRawTransaction, tenderly_sendTransaction.
  • Admin RPC state changes, such as tenderly_setBalance, tenderly_setErc20Balance, tenderly_setStorageAt, tenderly_setCode, and tenderly_setNonce, and their Hardhat and Anvil aliases.
  • Block and time controls: evm_mine, evm_increaseTime, evm_increaseBlocks, evm_setNextBlockTimestamp, and tenderly_setNextBlockTimestamp.
  • Reverts: evm_revert and tenderly_revertLatestBlock.
  • Filter calls: eth_newFilter, eth_newBlockFilter, eth_newPendingTransactionFilter, and eth_uninstallFilter.
Once the limit is reached, writes are rejected with HTTP 403 and the same -32004 error as a monthly usage limit, even when the Usage page shows low usage. Reads and simulations keep working. The count belongs to the Virtual Environment and doesn’t reset: fork the environment or create a new one to continue with a fresh count. To use Virtual Environments without a write limit, contact our sales team.

​
Usage history

The Usage page covers the current calendar month. For usage in earlier months, contact support at support@tenderly.co.