Tenderly Web3 Actions: where manual event processing breaks
While there are few events on the network, on-chain event processing relies on manual scripts for contracts: a scheduled job scans the log, compares the latest block height with the saved checkpoint, and sends notifications.
The scheme works exactly as long as the process stays alive and the on-call engineer remembers where it left off.
It breaks predictably. A restart after a crash resets the checkpoint — some calls are processed again, some are lost in the gap between passes, and missed contract events appear. Recovery has to be manual: pull up the history, match records, and add compensating actions.
Under peak load, the cycle cannot keep up with the stream, and the delay in reacting to transactions grows from the polling interval to the moment someone notices the discrepancy.
From the outside, it looks like “the system sometimes doesn’t trigger” — with no reproducible scenario and no boundary beyond which the failure becomes critical.
A separate matter is chain reorganization: an already processed call may cease to be part of the canonical chain, while the script does not find out and continues to consider the state consistent.
This class of discrepancies is the slowest to close through manual reconciliation, because what needs to be found is not a failure but an incorrect assumption.
Blockchain event automation via Tenderly Web3 Actions moves the trigger point to the event itself: the reaction starts at confirmation time, not on a schedule, and processing state is stored in the service.
Below, we break down how this closes the gap and what exactly stops depending on the on-call engineer.
What network event reaction automation provides
Manual monitoring is polling: a script fetches events every few minutes and reacts after the fact, so the time between event and reaction ranges from a minute to several hours.
All that time, stuck transactions and unprocessed requests silently pile up, and the discrepancy between network state and service state grows.
The event-driven model removes both polling and delay.
Subscribing to a contract address and event signature launches the handler at block inclusion time — reaction time drops to seconds, and the share of manual operations shrinks to exceptions: typical reactions live in code, and the engineer only handles what the handler flags as atypical.
At the same time, an entire class of failures goes away — a missed window, reprocessing the same event after a failure, acting on stale state.
Retries and idempotency are built into the execution model, and the run log stores input, output, and error cause, so an incident is investigated based on facts rather than scattered logs.
Tenderly Web3 Actions covers this without your own handler fleet: code is deployed next to the node, sees network state, and is tested locally, while keys and secrets are stored outside the repository.
The service runs around the clock — a nighttime request is processed the same as a daytime one, and stability stops depending on whether someone is on call at the moment of the event.
Web3 handler launch modes: comparison of approaches
Before enabling automation, what you choose is not a tool but the handler launch mode: it determines reaction delay, available libraries, and who is responsible for availability.
A single scenario — for example, moving funds to a reserve when liquidity is withdrawn — can be implemented by all four methods, but their failure classes and maintenance burden differ.
Built-in Tenderly Web3 Actions triggers cover the case where the logic fits into ready-made conditions by contract address, event topic, and volume.
As soon as access to an internal database or a custom retry queue is needed, one platform is not enough — it is supplemented with a hybrid scheme or replaced by your own event handler.
| Launch mode | When it fits | Limitations |
|---|---|---|
| Built-in platform triggers | Reaction to a contract event by filter: notification, enqueueing, calling an external address | No custom libraries, long-running tasks, or local state |
| Custom event handler | You need your own dependencies, a retry queue, and access to internal systems | You handle availability, monitoring, and chain synchronization yourself |
| Hybrid automation scheme | Fast reaction to an event plus heavy logic in your own environment | Two environments: idempotency and discrepancy control are mandatory |
| Scheduled launch | Batch reconciliation, reports, backfilling missed events, one-off migrations | Delayed reaction; not suitable where speed matters |
The modes are compatible with one another and are combined in practice: a built-in trigger catches an event and passes the task to your service, while a schedule backfills what was missed. Contracts do not need to be changed — automation is built on top of already deployed ones.
Implementation sequence: from event audit to handover
Automation on Tenderly Web3 Actions breaks not on the handler code but on an incomplete map of contract events. A missed transfer emitted not by the contract logic but by a token leaves the scenario unhandled — and it surfaces as an accounting discrepancy. That is why we start with an inventory.
- Contract event audit. We parse the ABI and logs: a complete list of signatures, indexed fields for filters, and separately events from proxies, libraries, and related tokens.
- Event processing scheme. We mark what triggers an action and what is only written to the log, and define the idempotency key “transaction hash + log index” — redelivery will not duplicate the operation.
- Side effects. We determine where the result goes: an external HTTP call, a database write, a notification. Secrets — only in environment variables; requests — within the action execution time limit.
- Handler testing on a test network. We test on a fork: the required events, re-emission, block rollback, an unavailable external service. Each scenario is a run with an expected result.
- Deploying automation to the production network. We enable it gradually: one address or event type, then expand. The run log and an alert on unsuccessful triggers reveal a filter error within the first minutes.
- Handover of the solution to the team. We hand over the repository, the event and filter scheme, environment variables, access rights, and the procedure: how to add an event, disable an action, and roll back to a previous version.
After handover, the team adds events and changes filters on its own, and we get involved for contract changes.
What remains in the repository after implementation
After implementing automation on Tenderly Web3 Actions, the repository retains not only the handler code but the entire support loop around it. The point is for the on-call engineer or a new developer to understand the event flows without the author. Below is the list of artifacts we hand over and check at acceptance.
- Handler configurations. For each trigger, the network, contract address, event signature, filtering conditions, and action set are fixed. Changes go through review rather than being edited by hand in the web interface.
- Event flow scheme. A diagram “contract → handler → side effect”: database write, notification, call to another contract. It marks failure points and behavior on re-run.
- Secret access policies. A list of keys and tokens: what is stored in protected variables, who has access, how rotation works, and what to do in case of compromise.
- Logging. A unified record format: event identifier, contract address, transaction hash. Incident investigation starts with a search through the log, not with guesses.
- Failure handling procedure. Errors we retry with increasing delay are separated from those we suppress immediately; attempt limits and notification recipients are defined.
- Test environment. Scenarios on a local testbed and a run on a network fork: re-run, empty response, unavailable external service.
- Automation documentation. A handler map, list of environment variables, deployment procedure, and instructions for the on-call shift: what to check in the first minutes and which actions are safe.
Case study: automating payouts based on staking events
The project was a staking pool where rewards were credited manually: an operator exported a list of events once a day, verified addresses, and launched transfers in a batch.
At peaks the queue grew, the delay between event and payout stretched to several hours, and each payout required separate confirmation — dozens of manual operations per day.
The bottleneck was found not in the transfers but in the lack of idempotency: when an event was redelivered, the handler could send the reward twice, so the operator checked every hash by hand.
The first step was a log of processed events with a unique key and status — re-running stopped being a risk.
The automation was built on Tenderly Web3 Actions: a trigger on a contract event calls the handler, which checks the event by key, sets a lock, and initiates the payout.
If the transaction fails, the handler retries on a schedule with a cap on attempts and writes the failure reason to the log — the operator gets involved only for flagged cases.
Metrics before and after
Time from event to payout decreased from hours to seconds, the share of manual confirmations fell to a few percent — only failures requiring a decision remained.
Re-runs became more frequent, but they are safe retries: the idempotency key did not let a single duplicate through to the network, and no discrepancies remained in balance reconciliation.
How event subscription differs from periodic polling
Periodic network polling is a scheduled cycle: the service itself asks the node every N seconds whether new blocks and logs have appeared for the required addresses.
Event subscription flips the scheme — the node itself delivers data as soon as a transaction enters a block, and the handler launches on fact. The difference is not convenience but how each model distributes delay, load, and the risk of losing an event.
Event detection delay under polling cannot be less than the cycle interval. Shrinking the interval means multiplying the number of requests: on active addresses and during peaks, the node starts returning rate-limit errors, and some requests simply do not get through.
With subscription, the event goes to the handler immediately after the transaction is included in a block, so the delay is measured in block seconds, not in cycle length.
Node load is structured differently. Polling wastes requests: most of the time there are no new events, but traffic flows constantly and grows linearly with the number of monitored addresses.
Subscription holds a single connection and transmits only useful data — with the same amount of logic, the node is loaded many times less.
Completeness of data processing is the main argument. Polling with a cursor of the last processed block misses an event if the process crashed between writing the cursor and processing, or if the chain reorganized.
Subscription by itself is also not a guarantee: the handler must be idempotent, and events must be deduplicated by transaction hash and log index.
In practice, we keep subscription as the primary channel and periodic reconciliation by block range as a safeguard that covers gaps and reorganizations.
Tenderly Web3 Actions provides both sides: triggers by contract events and calls, re-run on failure, and an execution log that shows at which block processing stopped.
Common technical doubts before starting
Automating reactions to events in Tenderly Web3 Actions seems simple until you start counting failures: the handler crashed midway, an event arrived twice, the node returned a timeout.
Below are the doubts engineers raise before starting and how we address them at the configuration level.
What if the event handler crashes midway?
A failed run is not lost: the input event and error stack are saved. Retries proceed with increasing delay and an attempt limit, after which the event goes to a separate queue for investigation — the stream is not blocked.
Can the handler run again on the same event?
Yes — on a retry after a timeout or during block reindexing. That is why we design actions to be idempotent: the key is the transaction hash and event number, and a repeat updates the same state rather than creating a duplicate.
Do you get access to private keys?
No. Secrets are stored in a protected vault and injected into the handler environment, not into the code. We move signing to a separate relayer wallet with limited permissions: the action forms an intent, and the key remains outside the execution scope.
Will automation work with already deployed contracts?
No code changes are needed: the action subscribes to events by address and interface description. We process past events with a pass over a block range, then live subscription is enabled.
What happens during network congestion or an event spike?
We set a limit on concurrent runs and batch reads so as not to hit node limits. On timeout, the run is retried with a delay, and the queue is processed by priority.
Let’s discuss your task and come back with a plan
To make the estimate of the scope of work for configuring Tenderly Web3 Actions substantive rather than approximate, we need context on your network and contracts.
Scoping the task takes one or two calls with the engineer who will lead the implementation — after that we come back with a stage-by-stage work plan and timelines. Below is the input data for starting; some points can be covered right in the conversation.
- Contract addresses, networks, and events whose reactions need to be automated — these will determine the set of triggers.
- How you learn about events now: manual monitoring, custom scripts, external services — this will show what exactly we are replacing and what we are keeping.
- What actions should be performed in response: notification, database write, internal service call, transaction sending.
- Reliability requirements: how many retries on failure, whether idempotency, an execution log, and error notifications are needed.
- Access and constraints: test networks, private nodes, security policy, who owns the signing keys.
- Desired implementation timeline and the date by which automation should be running on the production network.
We come back with a scope estimate, a trigger scheme, and a sequence of stages: what we roll out first and what can be added after launch. Describe the automation task in free form — we will clarify the rest on a call.