Wrong reminder after a reschedule? Fixing cancellations and timezone errors

Symptom 1: reminders for a time that no longer exists

This is the most common fault. A reminder is scheduled when the booking is created, as a separate delayed task. When the booking changes, nothing tells that task.

Two reliable fixes:

1. Cancel and recreate. On any change event, find the queued reminder for that booking ID, cancel it, and schedule a fresh one.
2. Check before sending. When the reminder fires, look up the booking again and only send if it still exists at the same time. This is simpler and survives missed change events, at the cost of one extra lookup.

The second approach is often more robust for small setups, because it does not depend on catching every change event.

Symptom 2: cancelled bookings still get reminders

Cancellation events can arrive late, be filtered out by a connector, or come from a different source (a staff member cancelling in the calendar instead of the booking tool). Check:

• Which systems can cancel a booking, and whether each one sends an event your automation receives.
• Whether your filter only listens for "booking.updated" and ignores "booking.cancelled".
• Whether staff sometimes delete calendar events instead of cancelling, which may produce no event at all.

The "check before sending" pattern above catches most of these.

Symptom 3: the time is an hour (or a day) off

Timezone bugs come from three places:

• The customer and the business are in different zones, and the message shows the wrong one, or doesn't say which.
• Daylight-saving transitions. A reminder scheduled as "24 hours before" across a clock change can arrive at an unexpected local time. Countries change on different dates, and some don't change at all.
• A server or tool default zone (often UTC) used to format the time.

Timezone rules are maintained in the IANA time zone database, which most software uses under the hood. The practical rules: store the appointment instant together with its location's timezone name (such as America/Chicago), not a fixed offset like "-06:00"; format times for the place where the appointment happens; and write the zone into the message when customers may be elsewhere.

Symptom 4: duplicate messages

If the booking tool sends both "created" and "updated" events for a single booking, an automation listening to both may send two confirmations. Use a booking ID plus status check, and keep a record of which message was sent for which booking version.

A test script to run before launch

Use test bookings with fake contact details that go to your own inbox or phone:

• Book, then reschedule to another day. Only one reminder, for the new time.
• Book, then cancel. No reminder.
• Book, cancel from the calendar (not the booking tool). No reminder.
• Book a slot just after a daylight-saving change. Correct local time.
• Book as a customer in a different timezone. Times are clear to both sides.
• Reschedule twice quickly. No duplicates.

Keep the results in your automation runbook so the next person can rerun them after any change. Booking tools document their own event types — see the Cal.com docs or Calendly help centre if you use them.

Questions

Sources and further reading

• IANA time zone database iana.org
• Cal.com docs cal.com
• Calendly help centre help.calendly.com

Official documentation changes. Check the current version before you rely on a rule, limit or setting.