Reminders and delivery

What gets sent automatically, and how to tell whether it arrived.

Every guest holding a ticket is reminded twice: the evening before, and again a few hours ahead on the day. The first is when a plan is made; the second is when it is acted on, and it carries the address at the moment somebody is deciding whether to leave the house. Both go in the language they booked in, and per ticket rather than per booking — a party of four is four people deciding what to do with their evening, and three of them never saw the confirmation.

Messages go out in the background. If delivery breaks — a sending domain that was never verified, an expired key — a panel appears on your event's Doors tab with the provider's own explanation, rather than everything looking fine while nothing arrives.

Sending an announcement later

An announcement can be written now and sent at a time you choose — "doors are an hour later tonight" is written the evening before and wanted at 16:00, when you are setting up a room rather than sitting at a keyboard. It is written down straight away either way; only the sending waits, and the history shows it as scheduled until it goes.

Anything timed — reminders, scheduled announcements, expiring waitlist offers — runs on a sweep that also happens whenever somebody opens the console. On a deployment with no scheduler wired up it is therefore not punctual, and /api/health says when it last ran.

An announcement first says how many people it was queued for — and then, once the messages have gone, how many were delivered, how many are still sending, and how many could not be delivered at all. Queued and delivered are different numbers, and the history keeps them apart rather than letting the first stand in for the second.