Skip to main content
This guide covers setting up both simple and complex alerting rules using Tenderly’s API. We’ll explore each expression type and then combine them into sophisticated monitoring solutions.

Alerting API reference

Introduction

Tenderly’s Alert API allows you to create simple and complex Alerts. A simple alert consists of one rule, for example method_call will get triggered when a transaction invokes your public or external method. A complex alert can have several conditions, and will get triggered when all of them are met. For example, an alert with method_call and state_change will trigger when a transaction calls the given method and updates the specified storage slot. When defining an Alert using the API, you need to specify the following:
  • delivery channels that get notified when alerting rule is triggered. See more about Delivery Channels.
  • expressions array that will trigger the alert when all conditions represented by individual expressions are met.
Email, Discord, and Sentry delivery channels can be created via the API (POST /api/v1/account/{accountId}/delivery-channel). Slack, Telegram, and PagerDuty channels require the OAuth/bot connection flow and can be created only via the Dashboard. All channels can be fetched using the API.

Authentication

Before creating alerts, you’ll need to set up authentication and identify your project:

Expression Types

You can use different expression types for specifying Alerts’ trigger rules.

Notes

  • These are all the expression types the API accepts. A payload with any other type value is rejected with a 400 (“Expressions are not in the right format”).
  • All expressions within an alert are AND-ed: the alert fires only when every expression matches the same transaction. To monitor independent conditions, create a separate alert for each.
  • For comparison operators (operator), valid values are: >, >=, <, <=, ==, !=, contains, notContains
  • Parameter types (parameter_type) include: uint, int, bool, address, string, slice, array, tuple, fixed_bytes, bytes, hash, function
  • The expression types emitted_log, erc20_transfer_matcher, eth_balance, tx_value, method_call, state_change, tx_status, and view_function support an optional not: true field that negates the match
  • erc20_token_transfer rules: set either addresses or match_any, not both. address_tag narrows match_any to tagged project addresses. With no token_addresses, the token scope is the project’s ERC-20 contracts (narrowed by token_tag, or widened to any token by match_non_project_contracts). require_dollar_value: true skips transfers of tokens without a known USD price and is accepted only with match_non_project_contracts. min_amount and max_amount are inclusive, compare the absolute amount, and require exactly one entry in token_addresses. With net: true, direction and amount apply to the net balance change per address and token in the transaction. See ERC-20 token transfer monitoring.
  • eth_balance fires only when a transaction moves the balance across the threshold (from non-matching to matching), not on every transaction while the condition holds
  • All addresses must be valid Ethereum addresses (0x prefixed, 40 hex chars)
  • Wei values should be passed as strings to handle large numbers
  • Network IDs should match the target blockchain (e.g., “1” for Ethereum mainnet)
For more details, explore the Alerting API reference.

Simple expressions examples

Explore examples of setting up simple expression rules.

1. Method Call Monitoring

Use Case: Monitor specific function calls in your smart contract.

2. State Change Monitoring

Use Case: Monitor changes in contract state variables, especially useful for tracking critical parameters like paused state or balance thresholds.

3. Event Monitoring

Use Case: Monitor specific events emitted by your contracts, with parameter filtering.

4. Native ETH Balance Monitoring

Use Case: Alert when an address’s native ETH balance falls below a threshold, for example a relayer or operations wallet that must stay funded. Scope the alert to a network and an address, then compare the native balance against the threshold (in wei).

5. ERC-20 Token Transfer Monitoring

Use Case: Alert when a treasury wallet sends at least 100,000 USDT on Ethereum mainnet. The network expression pins the alert to one network, and min_amount is in raw units (USDT has 6 decimals). ERC20 Token Transfer describes each field.
To watch every project address instead of one, replace addresses with "match_any": true, optionally with "address_tag". To cover every project token, omit token_addresses; amount bounds require a single token, so remove min_amount and max_amount as well. To match any ERC-20 token, including tokens not added to the project, omit token_addresses and set "match_non_project_contracts": true. Add "require_dollar_value": true to skip tokens without a known USD price, such as spam and airdropped tokens. This expression fires when any priced ERC-20 token leaves a project address tagged treasury:

Complex Alert Examples

Explore examples of showing complex expression rules. The alert will get triggered when every expression in the expressions array is satisfied.

1. Security Monitoring System

Use Case: Comprehensive security monitoring combining multiple conditions:
  • Monitor admin function calls
  • Track large value transfers
  • Watch for blacklisted addresses
  • Alert on state changes to critical parameters

2. DeFi Protocol Monitor

Use Case: Monitor a DeFi pool for:
  • Large trades/swaps
  • Liquidity changes
  • Failed transactions
Because expressions within an alert are AND-ed, each condition is a separate alert. The examples below create three alerts in one go.

3. ERC20 Token Monitor

Use Case: Token monitoring including:
  • Transfer consistency checks
  • Large transfer monitoring
  • Total supply changes
Like the previous example, each condition is its own alert.