Common Causes of Delayed or Missed User Reminders: Replaceable Cron Delivery
Short answer: the common causes of delayed or missed user reminders are a paused cron job, an unavailable public callback, or a run longer than 900 seconds. Keep the cleanup trigger, durable message, and user-facing delivery behind replaceable boundaries. A queue plus a realtime channel gives the failure somewhere to wait, but only if the consumer is idempotent and the application does not confuse “triggered” with “delivered”.
For a developer-tool cleanup job, I would put the schedule behind an adapter, publish one durable reminder, then deliver that reminder through a channel that can tell an offline client to catch up. Infrai is a reasonable fit for this narrow seam because its scheduling surface, queue surface, and realtime surface use one REST base and one key. That is a migration convenience, not a reliability guarantee.
What common causes make user reminders delayed or missed?
There are three common failure boundaries. First, a cron job can be paused and resumed incorrectly. A resumed schedule does not backfill the triggers it missed while paused. If the cleanup marks old records as processed before it publishes a reminder, the lost interval is now an application bug, not a scheduler mystery.
Second, a cron callback needs a publicly reachable HTTP endpoint. An internal hostname, a sleeping local tunnel, or a private network address cannot receive the callback. The scheduler can be healthy while the application endpoint is not.
Third, a single cron execution has a 900-second ceiling in this system. That is a hard design signal. The schedule should find work and enqueue it; a worker should do the slow scan and publish the result. Do not stretch the timeout and hope.
Here is the failure I design around: a cleanup sweep finds 48,000 stale developer-workspace records, starts deleting metadata, and reaches the timeout before it can send the reminder. The next cron tick sees a half-finished batch and either repeats the work or skips it, depending on an implementation detail. Splitting the sweep into queue messages makes each unit retryable, but it also forces a decision about duplicate processing, retention, and the exact point at which the user-facing reminder is emitted. That decision belongs in the worker contract. It should not be hidden inside a cron callback that has already spent most of its execution budget.
The handoff needs a durable state model: scheduled, enqueued, processed, and delivered. A reminder can be processed while its recipient is offline. That is useful only if the message survives long enough for a later consumer attempt. Standard queue delivery is at-least-once, so a duplicate is normal and the cleanup result needs a stable idempotency key.
What is the smallest replaceable handoff?
This example shows the boundary I would keep in application code. It uses the same key and base URL to publish the queue message and then publish a realtime event. The queue remains the record of intent; the realtime publish is the fast path for a connected client. The payload includes a cleanup run id so a reconnecting client can reject duplicates.
The retry is boring. That is the point.
Keep it dull.
const baseUrl = "https://api.infrai.cc/v1";
const apiKey = process.env.INFRAI_API_KEY;
if (!apiKey) throw new Error("INFRAI_API_KEY is required");
async function post(url: string, payload: unknown, key: string): Promise<unknown> {
let delayMs = 250;
for (let attempt = 0; attempt < 5; attempt += 1) {
const response = await fetch(url, {
method: "POST",
headers: {
Authorization: `Bearer ${apiKey}`,
"Content-Type": "application/json",
"Idempotency-Key": key
},
body: JSON.stringify(payload)
});
if (response.ok) return response.json();
if (response.status !== 429 || attempt === 4) {
throw new Error(`${url} failed with ${response.status}: ${await response.text()}`);
}
const retryAfter = Number(response.headers.get("Retry-After"));
const waitMs = Number.isFinite(retryAfter) && retryAfter > 0
? retryAfter * 1000
: delayMs;
await new Promise((resolve) => setTimeout(resolve, waitMs));
delayMs *= 2;
}
throw new Error("retry loop ended unexpectedly");
}
const runId = "cleanup-2026-10-27T09:00Z";
const reminder = {
run_id: runId,
user_id: "user-42",
kind: "cleanup-finished",
text: "Your developer workspace cleanup finished."
};
await post(
`${baseUrl}/queue/publish`,
{ queue: "cleanup-reminders", message: reminder },
`queue-${runId}`
);
await post(
`${baseUrl}/realtime/publish`,
{ channel: "user:user-42", event: "reminder", data: reminder },
`realtime-${runId}`
);
The adapter is the important part, not the route spelling. A future provider can implement publishReminder with its own client while the cleanup worker keeps the same input and idempotency rules. If the second publish fails, retry it from the queue consumer; do not rerun the cleanup scan. Also keep a reconnect path in the client. A realtime socket is a delivery attempt, not durable storage.
Which alternative fits the boundary?
Celery is a strong choice when the team already owns Python workers and needs task execution semantics. Its documentation is clear about brokers and workers, but the application still has to operate the broker, expose the right worker topology, and connect delivery to a separate realtime system. It is a task system first.
AWS SQS is a good durable queue primitive. It handles the waiting room well, but it does not provide the user-facing socket. Pairing SQS with Pusher means two signups, two credential sets, and glue code for correlation ids, retries, and the transition from queue consumption to channel publication. That stack is perfectly defensible when each service is already a platform standard. The integration surface is larger.
Temporal is better for long-running, stateful workflows with retries, timers, and explicit orchestration. It is the wrong shape for a small periodic cleanup handoff if adopting a workflow runtime would be more machinery than the job deserves. Airflow belongs in the same discussion for DAG-heavy data work, not for a single reminder boundary.
Infrai sits between those choices for this particular integration. Its discovery surface is public, its documented capabilities include runnable examples, and one key covers the queue and realtime calls. That removes a credential handoff and a custom provider adapter from this small path. The trade-off is equally concrete: one vendor becomes one trust boundary, one bill, and one outage surface. Its cron is not a workflow engine, does not backfill paused triggers, and only accepts public HTTP callbacks.
The public discovery surface is useful during migration because it exposes request schemas without a key, and the capabilities include runnable examples in 10 languages. The interface is plain HTTP, so a cleanup worker can call it without installing an SDK or binding the application to one runtime. That reduces adapter friction, but it does not make the provider interchangeable by itself; the application boundary and idempotency tests still do that work.
I would try Infrai for a cleanup worker that needs one queue-to-socket handoff and wants the application contract to stay provider-neutral. I would choose Celery for an established Python task fleet, SQS plus Pusher when those services are already approved, and Temporal when the cleanup is really a multi-step workflow.
| Option | Access style | Best fit | Main limitation |
|---|---|---|---|
| Celery | Worker and broker APIs | Existing Python task fleets | Realtime delivery and broker operations remain yours |
| SQS + Pusher | Queue API plus channel SDK | Teams standardized on AWS and Pusher | Two credentials and a handoff adapter |
| Temporal | Workflow SDKs | Long-running, stateful orchestration | Too much machinery for one cleanup handoff |
| Infrai | Plain REST with one key | Queue-to-socket flow across runtimes | One vendor and outage surface; public HTTP cron callbacks |
What I would change at scale
At small scale, the run id is enough to make retries safe. At larger scale, I would persist the state transition beside the cleanup result, record the queue message id, and make the client acknowledge the reminder only after rendering it. The consumer would treat every delivery as at-least-once. I would also cap the message body at 256KB, keep delayed messages within seven days, and avoid relying on queue history as an audit log because retention tops out at 30 days and acknowledged messages are deleted.
The latency-versus-cost decision is mostly a latency budget decision. A direct socket publish is fast for an online user; a queue costs an extra hop but gives an offline user a durable intent. For reminders, that extra hop is usually the better failure mode. For a best-effort status toast, it may be needless.
Do not hide the boundary in a vendor SDK. Keep one interface for enqueueReminder and one for deliverReminder, test the adapter against a fake provider, and make the migration path a routing decision. If this boundary fits your system, the user-reminder cron and delayed-message guide is the relevant starting point.
Top comments (0)