Recover a booking reminder after a receiver outage

A booking reminder can outlive the reason it was scheduled. If your receiving endpoint goes offline before an appointment, restoring the endpoint is only part of recovery. You also need to decide whether a delayed reminder would still help the customer. This hypothetical runbook starts with an existing reminder and ends with a recorded business outcome.

Give the reminder a useful lifetime

Store the booking identifier, reminder revision, intended delivery time and a latest useful time in your application. Choose that deadline from the product rule: a preparation reminder may become pointless before the appointment even begins. This deadline is application state, not an additional scheduling API field.

Decide what should happen after the deadline. Skipping an obsolete reminder is often better than sending it hours late, but an operational alert or a different follow-up might be appropriate. Treat a different follow-up as a separate product decision, not permission to replay every failed message. Record the reason for whichever outcome you choose.

Make the original request traceable

The illustrative server-side request below schedules work one day from execution. Adapt its time to the booking's reminder policy and make the resource identifier point to the particular reminder revision. Keep the usefulness deadline in the application record that the receiver reads.

Illustrative server-side example: this schedules delivery 24 hours from execution. Replace the environment variables and example record IDs, persist the returned job ID, and implement your own authenticated HTTPS receiver. The request follows the current API reference.

const apiKey = process.env.WEBHOOK_SCHEDULER_API_KEY;
const receiverUrl = process.env.REMINDER_WEBHOOK_URL;
if (!apiKey || !receiverUrl) throw new Error("Set the server-side API key and public HTTPS receiver URL.");

const response = await fetch("https://webhookscheduler.com/api/v1/schedule", {
  method: "POST",
  headers: { Authorization: `Bearer ${apiKey}`, "Content-Type": "application/json" },
  body: JSON.stringify({
    url: receiverUrl,
    method: "POST",
    runAt: new Date(Date.now() + 24 * 60 * 60 * 1000).toISOString(),
    reference: "booking:example-123",
    idempotencyKey: "booking-example-123-reminder-v1",
    body: { resourceId: "example-123" },
  }),
});
if (!response.ok) throw new Error(`Scheduling failed: ${response.status}`);
const job = await response.json();
if (!job.id) throw new Error("Missing scheduled job ID");
// Persist job.id with your business record before acknowledging this work.
console.log(job.id);

Persist the returned job ID beside that reminder. The API reference documents that repeating a scheduling key returns the retained original job. Recovering a lost creation response this way does not restart a failed delivery or change its scheduled time. Keep scheduling recovery separate from delivery recovery.

Locate the uncertain boundary

Inspect the existing job and its delivery attempts before creating more work. The documented job inspection view includes HTTP results and errors. A job still marked RETRYING has another recovery attempt scheduled; FAILED represents a terminal failure. Creating a second reminder while the first is retrying can make both act on the same booking.

Compare that evidence with your receiver's durable reminder record. A connection failure before the handler ran, a database failure inside the handler, and a timeout after a notification provider accepted a message have different recovery paths. The absence of a successful HTTP response does not prove that no customer message was sent.

For an uncertain external result, look up the notification provider's recorded outcome using the stable business identity where supported. If its outcome cannot be established, keep the reminder in an explicit uncertain state for investigation. This is a practical limit: without reliable outcome evidence, the runbook cannot promise automatic recovery without duplicate risk. Blind retries can turn a delivery incident into duplicate customer contact.

Check eligibility before permitting recovery

Once the receiver is healthy, load current booking state and the exact reminder revision. Confirm that the booking still exists, the reminder remains selected, its useful lifetime has not expired and no completed effect is already recorded. A corrected endpoint does not make an old intention current again.

Use the product's documented recovery controls only after that check, and have the receiver repeat eligibility checks when delivery arrives. The operating documentation is the starting point for inspecting and recovering jobs. This guide does not introduce a separate public retry endpoint.

Authenticate each incoming request before trusting its payload. Claim the reminder effect atomically in your application, and use the notification provider's idempotency facility where available. Keep a reconciliation path across that external call: a local database transaction cannot make it exactly once. Decide explicitly how to handle booking changes after the final eligibility check.

Close the incident with evidence

Use distinct application outcomes such as completed, skipped because obsolete, and uncertain pending investigation. Record the original job ID, the recovery decision and the final business outcome. A successful transport status alone is not evidence that the intended notification reached the customer.

Rehearse this runbook with a harmless booking record and a test effect: simulate an unavailable receiver, a repeated delivery, an expired reminder and an ambiguous downstream timeout. Do not contact customers during the exercise. The objective is to make each case explainable, rather than merely make the job list green.

WebhookScheduler is built by AllClearStack. It can provide delayed HTTP delivery and attempt visibility while these recovery decisions stay in your application. An existing database worker can also be suitable when it already owns booking reminders and their recovery. Use the workflow guides to keep transport responsibilities separate from the product's rules.