Custom Alerts for Critical Events

Hello! Welcome back to your course on Ethereum development.

Introduction

In our last lesson, we established the importance of operational monitoring and you learned how to connect your deployed contracts to services like Tenderly and OpenZeppelin Defender. You now know how to get a high-level overview of your contract's activity.

However, observing everything can be noisy. A popular dApp might have thousands of transactions a day, and most of them are routine. The real challenge is to cut through that noise to find the signals that matter.

This lesson focuses on exactly that, addressing the learning outcome: Configure custom alerts for critical contract events and function failures.

We will move beyond generic observation and learn how to create specific, conditional alerts that notify you only when something truly important happens. This is the difference between having a raw data feed and having an intelligent security and operations system. Given your front-end background, you can think of this as moving from a simple console.log to configuring fine-grained alerting rules in a service like Sentry or Datadog to catch critical application errors without being flooded by minor warnings.

By the end of this lesson, you will be able to:

• Explain the importance of high-signal, low-noise alerting.
• Configure alerts in Tenderly based on specific function calls and their status.
• Design smart contracts that emit structured events for better monitorability.
• Set up alerts that trigger on specific event emissions with conditional parameters.

1. The Problem: Alert Fatigue

In the previous lesson, you saw how to set up a monitor for all failed transactions. While useful, this can quickly lead to "alert fatigue." Imagine a popular NFT contract; you'll get an alert every time someone tries to mint after the collection has sold out. This is an expected failure, not a crisis.

The goal of a robust monitoring strategy is to achieve a high signal-to-noise ratio. We want alerts for events like:

• An administrative function like setOwner or pause is called.
• A large amount of funds is withdrawn.
• A core function that should always succeed, like an internal accounting update, suddenly fails.
• An event is emitted with suspicious parameters (e.g., a transfer to a known blacklisted address).

To achieve this, we need to create custom alerts that are far more specific than "any failed transaction."

2. Crafting Custom Alerts in Tenderly

Tenderly provides a powerful interface for creating these specific alerts. The core components, as you'll see, are the Trigger, the Target, and the Destination. Our focus will be on configuring the Trigger with precision.

Let's start with a practical demonstration of the basic alert setup flow.

Now that you've seen the basic flow, let's make it more specific.

Alerting on a Specific Function Failure

Instead of alerting on any failed transaction, let's configure an alert for when a specific, critical function fails. For example, imagine a function updateCriticalParameter() that should only be called by the owner and should never fail. A failure here could indicate a misconfiguration or a potential issue.

In the Tenderly alert creation UI, after you select the "Failed Transaction" trigger, you can add a condition. You would:

1. Click "Add Condition".
2. Select Function Name from the dropdown.
3. Choose the updateCriticalParameter function from the list of functions in your contract.

Now, you will only be notified if a transaction calling that specific function fails.

Alerting on a Successful Critical Action

Conversely, you often want to know when a critical action succeeds. For example, you should probably be notified every time ownership of your contract is transferred.

The process is similar:

1. Choose the Function Call trigger.
2. Select your contract as the target.
3. Add a condition for Function Name and select transferOwnership.
4. You can add another condition for Status and set it to Success.

This ensures you get a notification every time this sensitive administrative action is successfully completed.

3. Designing Contracts for Monitorability

While platform-level filtering is powerful, the most robust approach is to design your smart contracts to be inherently monitorable. The primary mechanism for this in Solidity is events.

By emitting well-structured events at critical points in your code, you create explicit, queryable "log" entries on the blockchain that are cheap and perfectly suited for off-chain tools like Tenderly.

Using Events and indexed Parameters

When you define an event, you can mark up to three of its parameters with the indexed keyword. This is crucial for monitoring. Indexed parameters are stored in a special data structure that allows off-chain services to search and filter for those events very efficiently, without having to read the data of every event ever emitted.

Let's review how to define, emit, and index events in Solidity.

A best practice is to emit an event for any state change that has security or operational significance. For example:

• Changing an admin address: emit AdminUpdated(address indexed oldAdmin, address indexed newAdmin);
• Pausing the contract: emit Paused(address account); (This is from OpenZeppelin's Pausable contract).
• Updating a critical fee parameter: emit FeeUpdated(uint256 indexed newFee);

4. Alerting on Specific Events

Now we can combine these two concepts: emit a specific event from your contract, and configure Tenderly to watch for it. This is the most precise and reliable way to create custom alerts.

Walkthrough: Alerting on a Paused Event

Let's use OpenZeppelin's standard Pausable contract as an example. It emits a Paused(address account) event when the contract is paused. We want an immediate notification when this happens.

In Tenderly:

1. Navigate to Alerting and click Setup Alert.
2. For the Trigger, select Event Emitted.
3. For the Target, select your deployed contract.
4. In the Event field, Tenderly will show a list of all events from your contract's ABI. Select Paused.
5. (Optional) You can add a condition to filter based on the account parameter of the event (e.g., if you only care when a specific admin pauses the contract).
6. For the Destination, choose Email, Slack, or another channel.
7. Click Save.

That's it. You now have a high-signal alert for a critical operational event, triggered directly by the logic in your smart contract.

5. Advanced Alerting: Webhooks and Automation

The final piece of the puzzle is what you do with the alert. An email is good, but what if you could trigger an automated response? This is where webhooks come in.

Your experience as a web developer makes you perfectly positioned to leverage this. Instead of an email, you can set the alert's destination to a Webhook URL. When the alert triggers, Tenderly will send a POST request with a JSON payload containing all the transaction and event details to your specified URL.

This enables powerful workflows:

• Triggering an incident in PagerDuty or Opsgenie.
• Sending a custom-formatted message to a private Discord/Telegram channel.
• Ingesting the data into a database for long-term analytics.
• Executing a script that performs a counter-measure on-chain (an advanced and high-risk action!).

Conclusion

In this lesson, you've moved from basic observation to creating precise, actionable alerts for your smart contracts. This is a critical skill for maintaining secure and reliable dApps in production.

Key Takeaways:

• Custom alerts are essential for avoiding "alert fatigue" and focusing on events that truly matter.
• You can create alerts based on specific function calls (both successful and failed) using the filtering capabilities of monitoring platforms.
• The most robust monitoring strategy involves designing contracts to be monitorable by emitting structured, indexed events for critical state changes.
• Combining contract-level events with platform-level alerting (e.g., Tenderly's "Event Emitted" trigger) provides the highest signal-to-noise ratio.
• Webhooks can be used as an alert destination to trigger automated off-chain workflows, connecting your smart contract's activity to the broader world of software infrastructure.

Next Lesson Preview:

Now that you can deploy, upgrade, and monitor your contracts with precision, we'll shift our focus back to the on-chain code itself, specifically its efficiency. In our next lesson, we will dive into gas optimization, covering the learning outcome: "Apply gas optimization techniques using storage packing and efficient use of calldata." You'll learn how to write code that does the same job for less cost, a vital skill for any serious Solidity developer.