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
  • 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).

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.