Answer the messages a support bot missed during a server outage, then switch the catch-up off

n8n recovery workflow screenshot from the post

Freelance automation developer Dmitry Prozorovsky runs an n8n-based AI support bot for a motorcycle-gear shop's VK community. When the client's server went down for 17 hours, they built a recovery workflow: it reads the server's up/down history from an outside monitor, waits until the server is properly back, answers only the messages that never got a reply, then turns itself off.

Try it yourself

What you get

A recovery workflow that waits for a confirmed recovery, replies to every message missed during an outage, and then turns itself off.

Tools

  • n8n
  • External uptime monitor API
  • VK community messages
  • Tool-calling AI agent

Time / cost: Not stated

Steps

  1. Watch the server from outside it, so the check still works when the server is down.
  2. After an outage, wait until the monitor history shows the server is stable again.
  3. Compare conversations with the bot's own records and reply only to messages that never got an answer.
  4. Look up live order status and prices at reply time, then switch the workflow back off.

Copy-ready prompt

Design an n8n recovery workflow for my support bot:
1. Trigger: poll [MONITOR] API every [N] minutes for my server's recent up/down history.
2. Start the backfill only after the server has been up for [N] minutes in a row.
3. Pull conversations from [CHANNEL] for the outage window and compare against the bot's reply log; keep only messages with no reply from the bot or a human.
4. Answer each one, fetching current order status and prices at reply time.
5. When the list is empty, deactivate the backfill workflow.
List the nodes, and how to avoid touching conversations a human is already handling.

Prompt written by AgentPlays, based on the workflow described in the interview. Check the output yourself and approve before anything is sent or bought.

Watch out: This comes from the monitoring vendor's blog. An always-on version first interfered with chats staff were handling by hand; keep it temporary.

Proof / source

Second-hand report Interview published by the monitoring vendor whose API the workflow uses (Oct 2026), not by the builder.

In their words

Build recovery tools to be self-limiting: something that watches for a real signal and then switches itself back off, rather than a patch that just runs forever and can end up causing its own bugs.

— Dmitry Prozorovsky (via UptimeRobot) on X

Read the original source ↗ Discussion ↗

Added · How we verify · Report an error

Related