Setting Up Tenderly Alerting: Smart Contract Monitoring and Alerts

Configuring Tenderly Alerting: Where Contract Monitoring Goes Blind

A standard transaction log records the fact: the call went through, the fee was charged, the status is successful. What it does not show is the meaning of the call.

Behind a successful transaction there may be a change of contract owner, withdrawal of the entire balance to a new address, or code substitution behind a proxy, and until manual reconciliation such an event remains unnoticed.

Key compromise unfolds in a single transaction: funds go to an address that previously had no involvement in the project’s life, and it has no “suspicious” status.

A quiet role change looks just as routine — a new account receives administrator rights, and only indirect signs show that access has been rewritten.

A contract logic update comes as a third scenario: the implementation address is different, the interface is the same, the behavior is not.

The reason is not a lack of data, but the absence of conditions under which the system raises an alarm on its own.

Configuring Tenderly Alerting closes exactly this gap: rules describe specific contract events — token issuance, permission changes, a large transfer, an implementation change — and transaction alerts go to a working channel, not an archive.

A threshold by amount and frequency separates normal activity from anomalous, so the signal does not drown in the flow of ordinary calls.

Next, we break down how such smart contract monitoring is assembled: which conditions catch anomalous activity on the blockchain, where signals arrive, and what to do in the first minutes after a trigger.

What Continuous Smart Contract Monitoring Provides

A smart contract does not crash with an error into a log — it continues to execute according to its code. Until a transaction becomes irreversible, neither support service nor a database rollback will stop it.

The only thing opposed to such an incident is the speed at which the on-call engineer learns about it and a response rule written in advance.

Reducing Time to Incident Detection

We build blockchain activity observability in Tenderly on rules: a contract event, a call to a specific function, a sharp change in an address balance, a spike in failed calls.

The rule triggers on a confirmed block, so a real-time alert is not disrupted by gas replacement and chain reorganization. The signal goes to the on-call shift chat and to the incident system — with the transaction hash, initiator address, and called method.

Previously, such a signal came after the fact: daily reconciliation, an email from a user, a discrepancy in a report. Now time to incident detection is measured in minutes, and a decision is made before the anomaly repeats with a second call.

Closing an Entire Class of Failures

Some failures are not visible in application metrics — they live only on the network.

Calling an admin function outside the release window, changing the contract owner, withdrawing a balance from a cold address, a series of transfers to a new address: previously, this surfaced during reconciliation, that is, after funds were already lost.

The rule is formulated for the first deviation from the norm, so interception occurs before irreversibility locks in the damage. According to our implementations, the share of anomalies caught before funds are lost grows from isolated cases to the majority of triggers.

Alert Modes: Comparing Technical Approaches

The same anomaly in Tenderly can be caught by different modes, and the cost of a mistake differs: in one case it is a missed withdrawal of funds, in another it is a stream of notifications that people stop reading after a week. Below are the options that are actually chosen between.

Choosing a Mode for the Task

They start not from ease of configuration, but from which class of failure is more expensive.

To protect funds, they set up transaction pre-check and add contract events as a second line; for treasury control, address tracking with threshold alerts by amount and operation frequency is enough.

Noise and False Positives

Thresholds are calibrated based on actual data: for a week, they watch triggers without reaction, then raise the boundaries and group similar events into one notification.

A rule that triggers ten times a day on normal operations stops being read within a few days — so the number of notifications per channel is kept within limits that the on-call engineer can actually handle.

Setup Stages: From Scheme to Handover to Operations

Alert setup begins not with the interface, but with inventory: as long as it is unknown which contracts and roles control money and permissions, any set of rules remains guesswork. Below is the work sequence we go through on every project.

Inventory of Contracts and Roles

We compile a registry: contract addresses, their state on the network, privileged roles — owner, administrator, issuer, pause — and the functions available to each.

We note where a role holds a multisig and where it holds a single key: this determines what to consider a critical event and what is noise.

1. Contract and role audit — we compare the registry with the actual network state, looking for roles left on a single key.
2. Alert scheme — we select events that require a response: owner change, large withdrawal, emergency pause, admin function call.
3. Rule connection — we set up Tenderly Alerting notifications for the selected contracts on testnet and mainnet.
4. Thresholds and routing — we define trigger conditions and distribute them across channels and urgency levels.
5. Trigger testing — we run test transactions and make sure the signal reaches the right recipient.
6. On-call policy — we record who responds, what we consider an emergency, and when we bring in the second line.
7. Handover to the team — we hand over access, rule descriptions, and the procedure for editing them without us.

Routing Triggers

Each rule gets a recipient and a level: critical events go to the on-call channel immediately, informational ones go as a daily summary. This way signals do not drown in the general flow, and the scheme remains readable for engineers who come after us.

What You Keep: Configurations, Schemes, Policies

After project handover, what you keep is not access to a panel, but a set of artifacts that lets the system be operated and developed without us.

Configurations are handed over to a repository next to the contract code: every edit goes through review and is not lost when the contractor changes or the on-call person changes.

• Export of configured alerts — rules as configuration files: trigger conditions, delivery channels, thresholds, message templates. They can be raised in a new environment without manual reassembly.
• Contract and role map — address, purpose, owner, which functions are privileged, and who holds admin keys. It immediately shows what exactly is affected during an incident.
• Threshold matrix — for each metric, the normal value, warning threshold, critical trigger threshold, averaging window, and acceptable signal delivery delay are specified.
• Key and secret access policies — who has access to which channels, how it is granted and revoked, where secrets are stored, and what is done if a leak is suspected.
• Response policy — for each event class, it describes who receives the signal, within what time they confirm it, what steps they take, and when they hand it over to a senior engineer.
• On-call engineer instructions — a checklist for the first minutes: how to distinguish a false positive, how to mute noise, where to view history, and how to hand over the shift.

What You Can Maintain on Your Own

Thresholds, delivery channels, and notification texts can be changed without us — these are configuration edits, not code changes.

The instructions cover two or three typical scenarios: adding a new rule, moving a threshold into observation mode, connecting an additional recipient. Expansion to new contracts is done by us, but here too you receive a template and a clear procedure.

Case Study: How They Stopped Missing Anomalous Transactions

What They Came With: There Were Alerts, But No Response

Monitoring existed formally: a rule triggered on any event above a given threshold and fell into a general channel together with build logs and node messages.

The on-call engineer received several dozen notifications per shift, of which one turned out to be useful, and stopped opening that channel first.

An incident confirmed this: the withdrawal of funds from the contract was discovered not by an alert, but by a user request, dozens of minutes later. The investigation showed that the needed event was in the logs, but drowned in the noise.

We rebuilt the scheme on Tenderly Alerting — not by amount threshold, but by the meaning of the event.

What Was Added After Launch

The first version of the rules caught everything indiscriminately: a contract migration and a spike of identical method calls produced an avalanche.

We added deduplication by address and a quiet window, and separated notifications by channel: role changes and parameter changes go to the on-call engineer, the rest go into the general flow. Absolute thresholds were replaced with deviation from the baseline over the previous week.

Incident investigation now takes minutes: the alert includes the address, method, and transaction hash, so the on-call engineer immediately sees the context instead of searching for it in logs.

How Do Event Alerts Differ from Transaction Simulation?

Event alerts answer the question “what has already happened”, simulation answers “what will happen if”. The first mode subscribes to contract logs: as soon as a transaction enters a block and leaves a record, Tenderly matches it against a rule.

The second runs a call against the current network state before sending and returns a verdict: it will pass, fail an access check, change balances, or affect another contract.

The blind spot of the event channel is everything that left no log. A reverted transaction writes no logs, so attempts to guess access, repeated failed calls, and admin function calls without logging go unnoticed.

Plus, an event records the consequence, not the intention: the channel will not tell you what will happen at the next step.

Simulation has the opposite blind spot: it evaluates only the submitted call, not what actually executes on the network.

If the decision is made in another contract, the verdict guarantees nothing, but every run produces a result — the stream of notifications grows even without incidents.

Therefore, in combined monitoring, channels are divided by task class. Event rules are kept strict — an event is a fact, false positives are few: owner change, contract pause, withdrawal above the usual volume.

Simulation thresholds are tied not to the fact of a run, but to its outcome: a specific failure reason or class of changed state.

Without such separation, notifications mix and people stop reading them — this is the main blind spot, when a channel formally exists but there is no trust in it.

Integration Concerns and False Positives

Alert integration is slowed not by technical limitations, but by organizational ones: who is responsible for the on-call shift and whether the stream of triggers will turn into noise that starts being ignored.

Below are five questions asked before the start. This concerns already deployed contracts: no reissue is needed, observation is external — via event logs and changes in address state.

How to remove false positives?

Three techniques: thresholds instead of reacting to every call, window aggregation — no more than one alert per interval, and splitting rules into critical and informational. Exceptions for service addresses remove routine, and noise drops severalfold.

How to send alerts to a messenger and an on-call system?

Via a webhook: the recipient receives a structured message and routes it — information to the work chat, critical items to the on-call shift with escalation. We configure delivery confirmation and retry when the recipient is unavailable.

Who investigates a trigger?

Responsibility for investigation is fixed by policy: a rule has an owner, and a critical one has a response deadline. The alert includes context — call, transaction, state change — so the on-call engineer does not collect data manually.

What to do about an incident that occurred before setup?

We reconstruct the chronology from events in blocks: we analyze past cases and set rules that would have caught them earlier.

Let's Discuss a Monitoring Scheme for Your Contracts

To discuss the task substantively rather than in general terms, a minimum of input data is needed: it determines which rules make sense at all and which will create noise. The list below covers data preparation entirely — from it we already see the scope of work and bottlenecks.

• Contract addresses with network and type: proxy, implementation, factory, and separately libraries if calls go through them.
• Role and owner scheme: who has administrator rights, who pauses the contract, who confirms issuance and burning.
• List of critical events: implementation upgrade, owner change, limit changes, large transfers, emergency stops.
• Current notification channels and what is already configured — so as not to duplicate rules and not create a second stream of signals.
• On-call mode: coverage hours, escalation procedure, who investigates a trigger outside working hours.
• Environment separation: where we test thresholds before production and whether rules need to be mirrored on testnet.
• Access restrictions: who issues keys for external notifications and whether there are requirements for storing the trigger log.

This is enough to come back with a work estimate and a monitoring plan. We build the implementation order from risk: first rules for critical functions, then sensitivity thresholds on historical data, then output to on-call and analysis of the first false positives.