Home / Blog / Migration Guide

OpenZeppelin Defender Is Shutting Down — Here's Your Migration Path

OpenZeppelin is sunsetting Defender's Autotask and Relay infrastructure. If you're running contract monitoring, dashboards, or automated responses through Defender, they stop working on shutdown. This guide covers what breaks, how to migrate to Sentinel, and what to watch out for during cutover.

What Defender Does — And What's Going Away

OpenZeppelin Defender has two core pieces that matter for monitoring:

• Autotasks — Serverless functions that run on Defender's infrastructure, typically triggered by sentry monitors watching contract events and executing webhook calls.
• Relays — Defender's built-in way to send transactions or deliver webhook payloads. If your monitoring relied on Defender's relay to deliver alerts, that disappears too.

The sunset means any Sentry/Monitor + Autotask pipeline you built to detect and act on contract events stops firing. If you're using Defender solely for transaction relay (e.g., multisig upgrade execution), that also goes.

What You Lose Without a Replacement

If you don't migrate, here's what stops working:

• Event monitoring — eth_getLogs-based monitors that trigger Autotasks stop polling.
• Alert delivery — Any Slack webhook, email, or custom endpoint triggered by a Defender Autotask goes dark.
• Dashboard access — Defender's web UI and API become inaccessible.
• Automated responses — Any scheduled or event-driven automation tied to your Defender Autotasks stops.

How Sentinel Replaces Your Defender Monitoring

Sentinel is built specifically for the monitoring and alerting piece that Defender is abandoning. Here's how the capabilities map:

Feature	OpenZeppelin Defender	Sentinel
Contract monitoring	Sentry monitors + eth_getLogs	24/7 eth_getLogs polling, multi-chain
Alert delivery	Autotask webhooks, SMTP relay	Webhook + email, no infra to maintain
Event types	Custom ABI or predefined	Transfer, OwnershipTransferred, Paused, Unpaused
Slack / webhook	Autotask code (JS/TS)	Native webhook endpoint, Slack-compatible
Dashboard	Defender web UI	Dedicated monitoring dashboard
Self-hosting required	No (SaaS)	No (fully hosted)
Monitoring since	Must be running for events to be caught	Continuous — events during gaps are missed either way

Migration Steps

1. Export your monitored contracts

In Defender, go to Contracts and note each contract address, network, and the event signatures you're monitoring. Defender doesn't offer bulk export — you'll need to pull this from the UI or API. Do this now before the Defender API goes read-only.

2. Identify your alert destinations

Review your Autotask code (or Defender monitor settings) to find every webhook URL, Slack channel, and email address receiving alerts. These destinations move to Sentinel as-is.

3. Create a Sentinel account

Sign up at sentinelweb3.com. The free tier covers up to 3 contracts with email alerts — enough to migrate and validate before committing to a paid plan.

4. Add your contracts in Sentinel

For each contract you exported from Defender:

• Add the contract address and network (Ethereum, Arbitrum, Base, Polygon)
• Select your event types — Sentinel monitors Transfer, OwnershipTransferred, Paused, Unpaused automatically
• Set your alert thresholds (e.g., flag transfers above a certain amount)
• Point your webhook URL or email address — no code to write, no infrastructure to spin up

5. Validate before cutting over

Use Sentinel's Test Alert feature to fire a synthetic alert to your webhook or email. Confirm it arrives correctly. This ensures your delivery path works before you remove the Defender monitor.

6. Decommission Defender monitors

Once Sentinel is receiving and delivering live events for at least 24 hours, disable or delete the corresponding Defender Sentry monitors. Don't do this before validating — there's no undo on the Defender side.

What Sentinel Doesn't Cover (Yet)

Sentinel focuses on event monitoring and alert delivery. If Defender was doing other things for you, here's where those map:

• Automated transaction execution — Sentinel monitors and alerts, it doesn't relay transactions or execute on-chain actions. For multisig automation, you'll need a dedicated solution (Gnosis Safe + a keeper service).
• Gas optimization / bid suggestions — Defender's relay had gas management logic. Sentinel doesn't touch gas — it just watches events.
• Contract verification / source code — Defender had Etherscan integration for verifying ABIs. Sentinel lets you paste ABI strings manually or use standard event signatures.

If you used Defender heavily for automated transaction relay, that's a harder migration. Sentinel is the right tool for the monitoring piece — you'll need a separate solution for execution relay.

Get Started

Migrating from Defender is straightforward if you treat it as a structured hand-off rather than a last-minute scramble. Export your contracts, set up Sentinel, validate your alerts, then decommission.