High-Priority Alerts
The High-priority alerts card on Configuration → Advanced is where you decide what "something is wrong" looks like for your project — and how loudly Remo should say so. Configured well, you find out that the connection dropped or the bot stopped answering long before a client does.
Only project admins can see and change this card.
How an Alert Works
Every alert has the same shape. Remo watches one thing, compares it against a number you choose, and notifies your team when reality crosses that line. Nothing fires until you switch it on, so a new project starts out completely quiet.
After an alert fires it waits out its cooldown before it's allowed to fire again. That's what stops one bad afternoon from becoming fifty identical notifications.
The Controls on Each Alert
| Control | What It Does |
|---|---|
| Enabled | Turns the alert on. While it's off, nobody is notified no matter what happens. |
| Threshold | The number that has to be crossed before the alert fires — either a count of events or the length of a quiet window, depending on the alert. |
| Unit | What the Threshold is measured in — minutes, hours, percent, or count. Window-based alerts measure a stretch of time; the rest count events. |
| Cooldown (min) | How many minutes of silence must pass after a firing before the same alert may fire again. Raise it for the chatty alerts, lower it for the ones you never want to miss. |
| Push | Sends a push notification to the devices where your team has notifications turned on. |
| Sends the alert by email. | |
| Sends the alert as a WhatsApp message. |
Channels are chosen per alert, and you can tick more than one. A good rule of thumb: email for the alerts you'll read at some point today, push or WhatsApp for the ones that need someone to stop what they're doing.
Who Gets Notified
Alerts fan out to every member of the project. There's no per-person routing and no way to send one alert to one teammate only — so keep that in mind before enabling the noisier ones on a large team.
Test Fire
Test fire sends the alert immediately, through exactly the channels you've ticked, without waiting for the real condition to occur. Use it to confirm the plumbing works: that push notifications actually arrive on your team's phones, that the email doesn't land in spam, and that the WhatsApp number receiving alerts is the one you expected.
It's also the quickest way to discover that nobody on the team ever enabled notifications — the usual reason a carefully configured alert is never seen.
Recent Firings
Recent firings shows when each alert last went off. It's what separates a blip from a pattern: an alert that fired once last Tuesday is noise, while the same alert firing every morning is a problem worth chasing.
An empty list is normally the good outcome. If it stays empty for weeks on an alert you're counting on, run a Test fire to confirm it's wired up at all.
The Ten Alerts
| Alert | When It Fires |
|---|---|
| Empty WAHA message detected | An inbound text arrives with no body at all. This is almost never a client sending a blank message — it's a symptom of messages not being forwarded to Remo correctly. |
| No inbound messages | The project received zero inbound messages within the threshold window. On a number that's normally busy, this is one of the earliest signs the connection has quietly died. |
| No new contacts | No new contacts were created within the threshold window. Useful when your lead flow is steady enough that a gap means something upstream broke. |
| WAHA session unhealthy | The QR-based session is disconnected, logged out, or stuck on the QR screen. This one applies to projects connected with WAHA. |
| All agents unavailable | Every agent on the project is marked unavailable, leaving nobody for the bot to hand a client to. |
| Stuck conversation | A client's last message has gone unanswered beyond the threshold — neither the bot nor a person replied. |
| Outbound send failures | An outbound WhatsApp message failed to deliver. |
| AI response failures | The conversation pipeline failed, so the bot couldn't produce a reply. |
| Low project credits | The credit balance fell to or below the threshold. |
| Cron job failure | A scheduled background job failed — one of the routines Remo runs on a timer behind the scenes. |
What to Do When One Fires
The three most common alerts have a clear first move:
- WAHA session unhealthy — reconnect the number and scan a fresh QR code. Walk through WAHA Setup if the session won't come back.
- Low project credits — top up before the balance runs out, since the bot stops working once it does. See Credits & Usage.
- All agents unavailable — check the availability toggles on Communication → Agents. Someone usually turned theirs off at the end of a shift and never turned it back on.
The rest are worth a look at Recent firings first. A single firing after a busy weekend rarely means anything; the same alert three days running does.
Turning on all ten at once is the fastest way to teach your team to ignore alerts entirely. Begin with the ones that would cost you real money if you missed them — WAHA session unhealthy, Low project credits, and one activity alert such as No inbound messages — and give them generous cooldowns. Add the others only once your team trusts the alerts they already have.