Why Alert Redux

Why Alert Redux?

Home Assistant can already send a notification when something happens: that's an automation. An alert is different. It's a condition that needs attention, and it stays a thing (on your dashboard, on your phone, in your history) until the condition is over or someone has said "I've seen it". Automations are good at reacting; they're awkward at remembering what's outstanding, reminding about it, and knowing when to stop.

Home Assistant's built-in alert integration does a little of this, but it's configured only in YAML, watches only one entity's state, and has not grown in years. Alert Redux is a replacement, built to be set up in the UI and to cover the cases a real household runs into.

What you get

Set up in the UI. Alerts, notification groups, and defaults are all forms under Settings → Devices & services → Alert Redux, or on the admin card. There's no YAML to write, and no restart to make a change.

Many ways to decide when an alert fires. An entity in a state; a value above or below a limit; any template; separate criteria for starting and stopping; a trigger or an event that keeps the alert up for a while; another alert being ignored; or an automation saying so. See Choosing an Alert Kind.

A proper life cycle. Each alert is an entity, alert_redux.*, that is idle, active (firing, nobody has acknowledged it), ack (firing, acknowledged), or one of a few others. You can acknowledge it, snooze it for a while, or (as an admin) disable or suspend it, from the card, a phone notification, your voice, or an automation. Who did what is recorded.

Notifications that behave. Alerts send an on message, reminders on a schedule until someone acknowledges them, and a done message when they're over. On the mobile app, each alert's notifications replace one another and disappear when it's acknowledged, so your phone doesn't fill up with stale ones. They can carry buttons that do something (Close door). Alerts send to notifier groups (your phones, your speakers, persistent notifications), so changing who's told is done in one place. Quiet hours hold back the noisy ones at night; throttling stops a flapping sensor from flooding you.

Five priorities. Emergency, Critical, Warning, Notice, Informational. They order the card, colour it, decide what gets through quiet hours, and on an iPhone let the most important alerts break through Focus and silent mode.

A card. The Alert Redux card shows what's firing, most important first, with acknowledge, snooze, and the alert's own buttons; an admin card lists every alert and can create, edit, export, and import them. Both install with the integration.

Missing data is not "all clear". If a sensor goes unavailable, an alert says it has no data rather than quietly deciding nothing's wrong, and a firing alert rides out a brief dropout instead of ending and starting again.

Alerts that work together.

• Supersession: Door Left Open can silence Door Open while it's firing, so you hear about each situation once.
• Escalation: an alert can watch another, and speak up when that one has gone unacknowledged for half an hour.
• Keep until acknowledged: an alert can stay on the card after its condition has cleared (the freezer was warm at 3 a.m.) until someone has seen it.
• Generators: one definition makes an alert for every matching entity: every door, every battery, every plug with a label.

Voice. Assist understands "acknowledge the garage door" and "what alerts are firing?". Alexa and Google Home can use proxy switches and buttons.

Portable. Alerts export to YAML and import back, so they can be backed up, kept in git, shared, or copied between instances; every recipe in this wiki is an import file.

Compared with the built-in alert

	Built-in alert	Alert Redux
Configuration	YAML, restart or reload	UI forms (and import files)
What fires it	One entity in one state	State, threshold, template, on/off, triggers, events, other alerts, actions
Delays before firing and ending	No (only skipping the first notification)	Yes
Acknowledging	Turning the alert entity off	Acknowledge, snooze, unacknowledge; disable and suspend for admins
Priorities	No	Five
Reminders	Repeat intervals	A schedule per alert or by default, paused by acknowledging and resumed after a snooze
Notifications	A list of notify actions per alert	Notifier groups, replacing and clearing, buttons, quiet hours, throttling, retries and a fallback
Dashboard	An entities card	Its own card and an admin card
Missing data	Not handled	no_data, with a grace period for firing alerts
Many similar alerts	One block each	Generators

Compared with Alert2

Alert2 is a mature, capable alerting integration, and Alert Redux owes it several ideas (it's credited in the README). If it's working for you, there's no pressing reason to move. The main differences are in approach:

• Alert Redux is configured entirely through Home Assistant's own config entry forms and import files, and keeps nothing in YAML.
• Notifications go to notifier groups defined once, rather than notifiers named in each alert.
• It has a fixed set of five priorities that drive the card, quiet hours, and iOS interruption levels.
• Its generators choose their targets by labels, areas, domains, device classes, and entity ID patterns, and follow entities as they're added and removed.

If you're moving from either, a converter turns your existing configuration into an import file: see Migrating from alert and Alert2.

What it doesn't do

• No YAML configuration. Alerts live in Home Assistant's config entries. To keep them in files, export them (Keeping Alerts in Version Control).
• It isn't an alarm system. It tells people about conditions; it doesn't arm, disarm, or call anyone. Pair it with an alarm panel and automations for that.
• It doesn't send notifications by itself. It uses the notify actions and entities you already have (the mobile app, TTS, persistent notifications, and so on).

Requires Home Assistant 2026.6 or later. Ready to try it? Getting Started.