Cloudflare Durable Objects: How to Prevent Alarm Retries with ctx.abort()

Cloudflare has modified the lifecycle behavior of Durable Object alarms when ctx.abort() is invoked. Previously, an alarm interrupted by this method would automatically retry after the Durable Object reset. This change introduces an explicit opt-out mechanism for developers who need precise control over alarm execution.

To prevent an alarm from retrying, you must now pass { retryAlarm: false } as the second argument to ctx.abort(). This is particularly useful for cleanup tasks that delete storage, as it prevents the alarm from re-running or the Durable Object constructor from executing again.

Code Example

The following example demonstrates a CleanupTask that deletes all storage and then aborts the alarm with the retry option disabled:

import { DurableObject } from "cloudflare:workers";

export class CleanupTask extends DurableObject {
  async alarm() {
    await this.ctx.storage.deleteAll();
    this.ctx.abort("Cleanup complete", { retryAlarm: false });
  }
}

Concurrency and Default Behavior

A critical nuance is how alarms interact with concurrent requests. Alarms run alongside other requests to the same Durable Object. By default, the retry behavior prevents an unrelated request from permanently canceling an in-progress alarm.

However, if you want to stop an alarm, you must explicitly set retryAlarm: false on the abort call, not only on calls originating from the alarm handler. Existing calls to ctx.abort() retain the default retry behavior.

Development Requirements

For local development, the retryAlarm option requires Wrangler 4.126.0 or later.