Monitoring Your Catalogs and Channels

A monitor is a rule that keeps an eye on your catalogs and channels so you don't have to. You describe what to watch for — "product count drops sharply", "no successful import in a day", "the price field starts going empty" — and Renable checks it for you and raises an alert when it happens. You'll find your monitors on the Monitoring page in the top navigation.

Monitors are built for both ways of working: describe what you want in plain language and let Aimée set it up, or build one yourself on the monitor page. Either way you get the same monitor, and you can always open and adjust it later.

What a monitor can watch#

Each monitor checks one kind of thing:

• After each catalog import — the import's numbers: product count and how much it changed, new and removed products, how many warning types it raised, how full each field is, or simply whether the import failed. Its Run status is one of the statuses the catalog's Activity tab shows: OK, Issues, Warnings or Errors.
• After each channel run — the channel's numbers every time it runs: how many products made it in, how many were excluded, out of stock or archived, how much any of those changed since the last run, whether the run failed, or how it ended: its Run status is Published, Published with warnings, Publish held or Failed. A run is started by Publish or Regenerate, and the monitor checks once it has finished — after every run, including one a monitor held (Publish held) and one that failed.
• When an event is reported — reacts to warnings and errors as they appear anywhere in your account, filtered by how serious they are. Useful for relaying anything that needs attention to your inbox.
• On a schedule — checked regularly, for conditions about time: a catalog that hasn't had a successful import in too many hours, or a channel that hasn't published in a while. Its Latest run status is how the most recent import or channel run ended, including one that failed or was interrupted — a catalog's can also be No changes, Retrying or Skipped. Retrying is not a failure: the import was cut short and is being tried again automatically, and monitors that check after each import wait for the retry's result. One case does count as a failure: when the database cancels the same catalog's import three times in a row, the third attempt ends as Errors — see My feed import failed.

A monitor can watch all your catalogs (or channels) at once, or just the ones you pick. A monitor watching all catalogs checks each one separately — if two catalogs shrink, you get an alert on each.

What happens when a monitor triggers#

When the condition holds, the monitor triggers and does what its actions say — Raise an alert, Send an email, Hold the publish, Send a webhook, or any mix of them. Every monitor has at least one; the alert is optional, so a monitor can just email you.

• An alert appears on your dashboard's attention list and on the affected catalog or channel's Activity tab, like any other warning or error. It stays visible in the app for as long as the problem persists.
• An email goes out once when the monitor triggers — not a repeat every time the condition is checked.
• A webhook sends a message to another system when the monitor triggers, when it clears, or on every check where the condition holds — you choose which.
• When a later check passes — the next import looks normal, the field fills up again — the monitor clears on its own and its alert disappears. There's nothing to tidy up.

A monitor's card and status line show where it's triggered right now, whether or not it raises alerts. Its Activity tab keeps the history: each time it triggered or cleared, and every email and webhook it sent.

You choose whether an alert is raised as a Warning or an Error, and you can write your own alert text or leave it empty for an automatic summary of what was observed. Your own text is written the same way a condition is: observed values, the affected catalog or channel and links back into the app are picked from a list, so there is nothing to remember or spell correctly. The email a monitor sends can carry its own title and body written the same way.

A monitor with no condition#

The condition is optional. A monitor without one matches every check: every import, every channel run or every matching event. After imports or channel runs, that means it triggers on the first check and stays triggered — so it emails once, not every time. A monitor that reacts to events is different: it clears again once none of the events it watches is open.

A monitor like that which raises an alert publishes with a note, because the alert never clears: "This monitor has no condition, so its alert is raised on every catalog it watches and never clears — each of those catalogs shows as needing attention until you pause the monitor or add a condition." The dashboard lists it and the project's status reads Needs attention for as long as it runs.

A monitor on a schedule can't go without a condition — it would trigger once on everything it watches and never again — so publishing one is refused until you add one.

Holding a channel's publish#

A monitor that checks catalog imports or channel runs can also hold the publish: when it triggers, affected channels keep their previously published feed live instead of publishing the suspicious new one. Your ads keep running on the last good data, and the hold clears on its own as soon as a check passes.

While a publish is held, the channel page shows a Publish held chip, and the channel's Activity tab shows the run that was held. If you're confident the data is fine, you can still publish manually: press Publish on the monitor's alert, wherever you see it, or on the channel page, which asks you to confirm and offers Publish anyway. Publishing anyway doesn't clear the alert, and archiving the alert doesn't lift the hold — Renable won't let you archive the alert while the publish is still held. See Hold a channel's publish when something looks wrong.

Email alerts#

Email is its own action, and optional: a monitor can raise an alert in the app, send email, or both. Send to members of your team, or to any other address — a client, a shared inbox. Addresses outside your team must click a verification link before any alerts are sent to them.

A monitor can send more than one email, each to its own people and with its own wording — a short plain-language note to the store owner and a technical one to a shared team inbox, from the same monitor. See Email alerts and verified addresses.

Webhooks#

Send a webhook connects a monitor to another system — a CRM, a ticketing tool, an automation platform. Renable sends a JSON message to the https address you enter, and that system acts on it: a common use is turning every triggered monitor, or every import, into a task for someone on the team. Each webhook chooses its events — Matched, Triggered and Cleared — and Send test checks the address before you publish. A delivery that keeps failing raises an Error alert on the monitor. See Send monitor events to a webhook.

The monitors you start with#

Every organization comes with three monitors, already on:

• Import fails — raises an Error alert when a catalog import fails.
• Publish fails — raises an Error alert when a channel run fails.
• Product count drops sharply — raises a Warning alert when a catalog shrinks more than 30% between imports.

Each one also emails the people who are members of your organization when it is created, which at signup is you. People who join later aren't added automatically. They're ordinary monitors: open them to change who gets the email, adjust the threshold, pause them, or archive them.

Pausing, editing, and archiving#

• The switch on each monitor card — and on the status line at the top of the monitor page — turns it on or off immediately, without publishing. Pausing a noisy monitor takes one click and clears its open alerts, which is why a paused monitor's status line says it isn't checking anything.
• Edits are drafts: nothing changes what's being checked until you press Publish on the monitor page. Every published version is kept in history. A monitor you've never published isn't checking anything yet, and its status line says so.
• Monitors are archived, never deleted — from the card's menu, or from the menu on the monitor page's status line. Archiving clears the monitor's open alerts and keeps its history.
• Monitors only check catalogs and channels you're still using. When you archive a catalog, a channel, or a whole project, monitors stop checking it and clear what they had triggered on it — a channel in an archived project counts as archived here, even though the channel itself isn't. An import or channel run that was already running when you archived doesn't raise a new alert either.

Where to go next#

• Create a monitor — with Aimée or by hand.
• Hold a channel's publish when something looks wrong
• Email alerts and verified addresses
• Send monitor events to a webhook — and the payload reference for the receiving side.
• Monitors and alerts explained — the concepts in brief.