Email Alerts and Verified Addresses

A monitor's alert shows in the app — on the dashboard and on the affected catalog or channel. Email is its own action, per monitor, for the things you want to hear about without logging in; a monitor can raise an alert and email, or only email. A client's inbox, a shared team address, or just your own.

Turn on email for a monitor#

1. Open the monitor from the Monitoring page and find the Then section of its Rule tab.
2. Click + Add action and pick Send an email.
3. Fill in Send to. Team members and other addresses go in the same box:
   • Team members — anyone who's a member of your organization can be picked directly, no verification needed.
   • Other addresses — any address outside your team. Type it under Add an email address; Renable sends it a verification email on the spot, and it then appears in Send to like everyone else.
4. Publish the monitor.

A "Send an email" row needs at least one recipient. Publishing is blocked until it has one — the monitor's summary line at the top of the page says so, and pressing Publish with an empty Send to comes back with a message rather than going through. That's deliberate: a row that sends nothing is a promise the monitor can't keep, and it's better to hear about it now than to find out during the incident it was meant to warn you about.

To stop a monitor emailing, delete the row with the bin icon beside it. Emptying Send to is not the way to switch email off — it leaves a row that can't be published.

Sending more than one email#

A monitor can carry up to 10 separate Send an email actions, and each one is completely independent: its own Send to list, and its own Title and Body. Click + Add action again and pick Send an email a second time.

That's there for the common case where the same problem needs to be described two different ways:

• A short, plain-language note to the store owner: "Fewer products than usual are going to your ads today — we're on it."
• A technical one to a shared team or agency inbox, with the observed numbers and a link straight to the catalog.

A few things worth knowing:

• The same address can be on more than one of them. That's allowed and it means what it looks like: that person gets both emails, because they're two different messages.
• The order of the rows doesn't matter. Every action runs when the monitor triggers, so there's nothing to arrange — which is why there are no drag handles.
• Once you have 10, "+ Add action" says so. Delete one to add another.
• Every row needs its own recipients. Filling in one row doesn't cover the others: if any row's Send to is empty, the monitor can't be published until you either add someone or delete that row.
• A row can send to at most 25 people. Once Send to holds 25, it says so and nothing more can be added. For a bigger audience, send to a shared team address or a mailing list instead.

How verification works#

An address outside your team must confirm it wants these emails before any are sent:

• Adding an address sends it a verification email with a confirmation link. The link is valid for 7 days; if it expires or gets lost, use Resend next to the pending address.
• Until the link is clicked, the address shows in Send to as a dashed chip reading pending, and a line under the box says plainly that nothing is sent to it yet. You can save and publish the monitor with a pending address — it counts as a recipient, so it satisfies the "at least one recipient" rule; it just won't receive anything until the link is clicked.
• Once verified, the address receives alerts from every monitor it's added to. Verification is per address, not per monitor.

What the emails look like#

• One email per incident. You get an email when the monitor triggers — not a repeat on every check while the problem persists. If the monitor raises an alert, it stays visible in the app the whole time. Very rarely the same email arrives twice: Renable would rather send an alert twice than lose it.
• At most 10 a day per catalog or channel. A monitor whose condition keeps triggering and clearing sends each of its emails at most 10 times a day for the same catalog or channel; later ones that day are skipped. Days are counted in UTC.
• At most 200 a day for your whole organization, counted per recipient. An email to 3 people counts as 3. An email that would go past the day's 200 isn't sent at all, rather than reaching only some of its recipients.
• The email names the monitor and the affected catalog or channel, shows the observed numbers, and links straight to the right page.
• No email when it clears. When a later check passes, the monitor clears and its alert, if it has one, simply disappears from the app. A monitor with no condition never clears after imports or channel runs, so it emails once. If another system needs to hear about the clear, add a webhook that sends Cleared (see Send monitor events to a webhook).
• Every email is on the Activity tab. The monitor's Activity tab lists each time it triggered, with every email it sent and whether it went out — Sent, Failed, or Skipped. An email is skipped when it has no verified recipient, when the monitor was paused or archived before it went out, when the monitor no longer sends that email or its emails changed in the meantime, or when the alert's 10-a-day limit or your organization's 200-a-day limit was reached.

Writing your own title and body#

Under the Send to box, Customize the wording opens a Title and a Body you can write yourself. Both start filled in with the standard wording so you can adjust it rather than start from nothing, and both pick values with the same chips the condition uses — the monitor's name, the affected catalog or channel, why it triggered, a link back into the app.

The wording belongs to that one email row. If the monitor sends several emails, each has its own Title and Body — changing one never touches the others, and a row you leave alone keeps following the standard wording whatever the other rows say.

• Leave them alone and they follow the standard wording, including any later improvements we make to it. Nothing is saved until you actually change something.
• Reset to default on a field you've changed puts it back to inheriting the standard wording. Clearing the field yourself does the same thing — an empty title or body always means "use the standard wording", never "send nothing".
• Your text replaces the message only. The observed numbers, the link to the affected catalog or channel, and the footer are always added below it — so a custom body can never leave a recipient with no way back into the app.
• Pick values from the list rather than typing them. A value that can't be filled in is left in the email exactly as written, rather than quietly disappearing — honest, but not something you want a recipient to read. That's why there's a picker.
• A title can be up to 200 characters and a body up to 2,000. Your own alert text, if you write one, can be up to 500.

Managing addresses#

• Verified and pending addresses are shared across your organization's monitors — add an address once, use it anywhere.
• Removing an address from a Send an email row stops that row's emails to it; the address stays available for the monitor's other rows and for other monitors.

Tips#

• Write for the person, not for the problem. If two different people need to hear about the same thing, that's two Send an email rows, not one email trying to be both technical and reassuring.
• Relay everything that needs attention. A monitor that checks when an event is reported can forward every Warning and Error in your account to an inbox — the Anything needs attention suggestion on the Monitoring page sets this up.
• Email for people, webhooks for systems. When the alert should become a task in your CRM or ticketing tool rather than a message in someone's inbox, use Send a webhook instead of — or as well as — an email.
• Keep email for the monitors that matter. An alert shows in the app without email; reserve email for the conditions you'd want to be interrupted for.