Privacy

The countdown is computed locally in your browser and needs no account. Email reminders are optional, and they are the only feature that sends anything to a server.

The countdown (local)

• Your browser's time zone is read locally to compute the countdown. It stays in your browser.
• .ics calendar files are generated locally from the dates shown; they are not uploaded.
• Countdown pages store no account, no email address and no personal file content.
• No advertising trackers or third-party analytics are loaded on countdown pages.

Email reminders (optional, online)

The reminder form is only shown when the feature is enabled for the site. If you use it, the reminder service stores the following fields:

• the email address you enter. It is stored until retention or cancellation and is the address used to send the confirmation and reminder. HMAC-derived values computed from it detect duplicate requests and rate-limit by mailbox, so it is not used only to send;
• the event slug (for example, christmas);
• the occurrence date, as a YYYY-MM-DD calendar date;
• the lead time: 1, 3 or 7 days;
• the time zone you enter;
• the computed send time and delivery deadline;
• an opaque request id and the event rule version used to re-check the date;
• created, confirmed, consumed and finished timestamps where applicable;
• hashed confirmation and cancellation capability identifiers. The tokens themselves are not stored;
• outbox delivery state: state, attempts, available_at, deadline, claim_id, lease_until, provider_message_id, last_error_code and finished_at. An outbox row stores the delivery outcome and provider reference, never a token;
• HMAC-derived recipient lookup and request deduplication keys.
• rate-limit keys and counters. The key for the IP bucket is an HMAC derived from the IP address, never the raw IP address; the recipient and deployment buckets use HMAC-derived keys too. Buckets expire after their window: 1 hour for the IP bucket and 24 hours for the recipient and deployment buckets by default.

We do not store your raw IP address, and application logs do not include email addresses, IP addresses or tokens. Hosting infrastructure may still keep operational logs such as request metadata, error codes and timestamps under its own retention policy.

Confirmation, cancellation and retention

• Nothing becomes active until you submit the confirmation form (an HTTP POST). Opening the link only displays that form, so a link scanner cannot confirm. An unconfirmed request is pending only until the confirmation link expires: within 48 hours, and always before the reminder is due. If it is not confirmed, cleanup deletes the pending email address and its capability data.
• Cancelling from either email deletes the reminder row, including the email address, event slug, occurrence date, lead time, time zone and hashed capability identifiers, and suppresses a reminder that has not yet been handed to the email provider. Cancellation cannot recall an email that is already in flight or has been delivered.
• A confirmed pending request is purged 7 days after confirmation, which can be earlier than the reminder's delivery deadline: the reminder is derived from the subscription, not from the pending row. Subscriptions keep their payload until 7 days after their delivery deadline; terminal outbox rows are deleted 7 days after they finish; an expired unconfirmed request is removed once expired. Bounded cleanup runs periodically with a per-statement limit, so deletion happens at a run after each cutoff - never before it, and later under a large backlog.
• The reminder service does not log tokens. Platform/CDN request logs may still record full request URLs, and a confirmation or cancellation URL contains its capability token. Anyone holding that URL can act on the request until it is consumed, cancelled or purged, so request logs are sensitive: access is restricted and retention must stay short. Do not paste such URLs into tickets, analytics or error reports.

Email provider

When reminders are enabled, the reminder service uses Cloudflare Email Sending to attempt delivery. Cloudflare processes the recipient address and message content as the email provider and may retain delivery logs under its own policy. Provider acceptance is not a guarantee that an email reaches an inbox.

What we do not do

• No selling of personal data.
• No third-party scripts or advertising trackers.
• No use of the reminder time zone to infer your country.

Questions: see Contact.