n8n reminder after a Wait: re-check the booking first

Test record: run by Fractional HQ on 11 November 2026 on n8n 2.23.4, as replays of a real message. Version 1.0: runs 94131, 94132, 94134 and 94136. Version 1.1: runs 94282, 94283, 94284, 94286 and 94287. Every wait lasted minutes. Not tested: a wait of a day or more, restarting n8n during a wait, two reminders waking in the same second, a reminder outside Meta's 24-hour window.

Symptom

This is a fault we tested for and did not get, and we are writing it up because the runs show what the second read is worth. On 11 November 2026 we ran our WhatsApp booking template on n8n 2.23.4 with reminders switched on, and we set up three bookings so that each reminder would wake a minute apart.

The first booking was for 16:00, and we then took over the chat from Slack as a member of staff would. The second was for 16:30, and we cancelled it before its reminder was due. The third was for 17:00, and we handed the chat back to the bot before its reminder was due. All three waits woke on time, and only the third sent its reminder.

Why it happens

n8n's documentation for the Wait node says a paused workflow offloads its execution data to the database and reloads it when the wait ends, so the run resumes with the items it was carrying. The cancellation and the staff takeover each happened in a different execution, so the paused run had no way of knowing about either. If we had put the send straight after the wait, both of those bookings would have produced a reminder, one of them for an appointment that no longer existed.

The pattern that held

After the wait, the template reads the booking again from its bookings table by key, and it reads the chat's current mode. An IF node then lets the reminder through only when the booking is still there and the chat is still with the bot. The reminder for the cancelled booking found no row in that table and stopped. The reminder for the chat that staff had taken stopped at the mode check.

In version 1.1, built the same day, we added one more condition before the wait. A reminder is only queued when a booking was saved in that same run, so a reply of "you are already booked" no longer starts a second wait for the same appointment.

How we found it

On version 1.0 the three runs are 94131, 94132 and 94136. Nothing was sent for 94131, where staff had the chat, or for 94132, which run 94134 had cancelled. Run 94136 sent its reminder and Meta accepted it. When we repeated all three on version 1.1 the pattern was the same: run 94282 sent its reminder, while the cancelled pair 94284 and 94286 and the takeover run 94287 sent nothing. Run 94283 was the "already booked" reply, and it queued no wait. All of these were replays, which means runs we started from a real message sent from a phone, with the text changed.

What we did not establish

Every wait in these runs lasted minutes. We did not leave one waiting for a day or more, and we did not restart n8n while a run was waiting. We did not test two reminders waking in the same second. We also did not send a reminder outside Meta's 24-hour window, which is covered in its own note.

Written by Fractional HQ from its own runs. If your n8n behaves differently, email hello@fractionalhq.uk and we will correct the note.