Active Investigation: D1 Timeout Issues

[ColeMurray]

Experiencing random D1 timeout issues with unclear origin.

I've created an issue with Cloudflare here, https://community.cloudflare.com/t/d1-timeout-errors-on-small-database/923198

Issue is primarily experienced when creating a session, but have also observed in ScheduleDO

D1_ERROR: D1 DB storage operation exceeded timeout which caused object to be reset.
    at D1DatabaseSessionAlwaysPrimary._sendOrThrow (cloudflare-internal:d1-api:139:19)
    at async cloudflare-internal:d1-api:366:41
    at async AutomationStore.getOrphanedStartingRuns (index.js:14314:20)
    at async SchedulerDO.recoverySweep (index.js:23738:22)
    at async SchedulerDO.handleTick (index.js:23644:5)

[ColeMurray]

pasting community post for convenience

Recurring D1 timeout: "D1 DB storage operation exceeded timeout which caused object to be reset"

Problem

We're experiencing recurring D1 timeout errors on a production Workers Paid plan. The full error:

D1_ERROR: D1 DB storage operation exceeded timeout which caused object to be reset.

The error originates inside the D1 binding itself:

at D1DatabaseSessionAlwaysPrimary._sendOrThrow (cloudflare-internal:d1-api:139:19)
at async cloudflare-internal:d1-api:366:41

When this occurs, D1 becomes completely unresponsive for 60–80 seconds. All concurrent queries — from Workers and Durable Objects — fail with the same error at the same millisecond, then D1 spontaneously recovers and the next request succeeds normally (~150ms).

We have observed 3 incidents over a 48-hour window. No corresponding incidents were reported on cloudflarestatus.com.

Environment

• Plan: Workers Paid
• D1 Database Size: ~452 KB (19 tables, well under all documented limits)
• Read Replication: Not enabled
• Architecture: One Worker + several Durable Objects, all sharing the same D1 database binding
• Cron: * * * * * triggers a Durable Object that does 3–5 simple D1 reads per tick (~150ms total)

What we've ruled out

This is not a load or query issue:

• Database is tiny (452 KB)
• All queries that fail are simple indexed SELECTs that normally complete in <5ms
• Traffic is low — incidents occur during off-peak hours
• One of the three incidents had no concurrent Durable Object activity at all — just a single POST request from the web UI triggered the D1 stall
• The cron tick typically processes 0 items and completes in 150–300ms wall time
• We have only 2 rows in the table being queried when the timeout occurs

The error type doesn't match the documented description:

Per the D1 error reference, our specific error is:

D1 DB storage operation exceeded timeout which caused object to be reset.
Description: "A query is trying to write a large amount of information (e.g. GBs), and is taking too long."

We are not writing GBs — we are reading from a 452 KB database with indexed queries returning 0 rows.

Importantly, we are not getting either of the overloaded/queued errors that D1 documents for application-level contention:

• D1 DB is overloaded. Requests queued for too long.
• D1 DB is overloaded. Too many requests queued.

This suggests the issue is in D1's internal storage layer (the backing Durable Object), not in our query volume or complexity.

Incident pattern

All three incidents follow the same pattern:

1. D1 queries are succeeding normally (~150ms per tick, <5ms per individual query)
2. D1 suddenly stops responding — no error, just silence
3. Queries accumulate in the queue (Workers/DOs are blocked waiting)
4. After 60–80 seconds, all queued queries fail simultaneously with D1_ERROR: D1 DB storage operation exceeded timeout which caused object to be reset
5. The very next query succeeds normally — D1 is healthy again

The wallTimeMs on the stalled Durable Object invocations is 15,000–18,000ms with cpuTimeMs: 0–1 — they are doing nothing but waiting on D1.

Incident details

	Incident A	Incident B	Incident C
Date (UTC)	2026-04-24 ~03:20	2026-04-24 ~06:19	2026-04-26 ~01:04
D1 stall duration	~75s	>10s	~78s
Cron tick involved?	Yes	No	Yes
Concurrent load	Very low	Very low (1 web request)	Very low (1 webhook)
All errors at same ms?	Yes (±17ms)	Yes (±2ms)	Yes (±125ms)
Recovery	Spontaneous	Spontaneous	Spontaneous

Incident B is the most telling — no cron tick, no Durable Object contention, no concurrent writes. A single stateless Worker POST request that does a few D1 reads hit the timeout. The scheduler ticks immediately before and after were perfectly healthy.

Representative timeline (Incident C)

01:03:40.096  Request IVNT2TKV4DPWBYPP — DO tick completes normally (wallTimeMs: 296)
01:03:40.097  Request F3LHTE164LAJDE13 — DO tick starts, immediately stalls on D1
                                         (wallTimeMs: 18060, cpuTimeMs: 0)
01:04:06.718  Webhook triggers POST /sessions — hangs waiting on D1
01:04:07.474  Request 0FTAESVP2P0Y6DLZ — SessionDO init succeeds (no D1 dependency)
01:04:36.526  Webhook caller hits waitUntil() 30s timeout — POST /sessions never returned
01:04:58.001  Request F3LHTE164LAJDE13 — D1_ERROR surfaces (78s after stall began)
01:04:58.004  SessionDO repo secrets query also fails with D1_ERROR
01:04:58.009  Request 2UYIM354P8B33MG8 — next tick succeeds normally (wallTimeMs: 151)

Note the 1ms gap between IVNT2TKV4DPWBYPP (success) and F3LHTE164LAJDE13 (78s stall) — same Durable Object, same query, completely different outcomes.

Impact

When D1 stalls during a session creation request, the Worker never returns a response. The caller times out, but a Durable Object that was already initialized continues running — resulting in an orphaned sandbox that boots but never receives its task. The user sees a session that appears to start but never does anything.

Stack trace

The error always originates in the D1 binding internals:

Error: D1_ERROR: D1 DB storage operation exceeded timeout which caused object to be reset.
    at D1DatabaseSessionAlwaysPrimary._sendOrThrow (cloudflare-internal:d1-api:139:19)
    at async cloudflare-internal:d1-api:366:41
    at async <our application code - simple indexed SELECT>

The class name D1DatabaseSessionAlwaysPrimary confirms read replication is not enabled.

Questions

1. What causes the D1 internal "object reset"? The error message mentions an "object" being reset — is this D1's backing Durable Object? Is it being migrated, evicted, or hitting an internal storage timeout?

2. Why does the stall last 60–80 seconds? The documented query timeout is 30 seconds, but the total D1 unavailability window is 60–80 seconds. What internal timeout governs this?

3. Would enabling read replication help? If the D1 primary is being reset, would read replicas remain available? Most of our D1 queries during the stall are reads that don't require read-your-own-writes semantics.

4. Is there any known issue with D1 primary DO placement/migration causing transient stalls? The spontaneous nature and low-traffic context suggest an infrastructure-level event rather than application-side contention.

5. Is there recommended retry/resilience guidance for this error? The D1 error reference recommends "Optimize the queries, send fewer requests, or shard the queries" — but this doesn't apply when the failing queries are trivial indexed reads on a tiny database. Is there a retry strategy that would help with the underlying storage-layer timeout?

6. Is the error description accurate for our case? The docs describe this error as "A query is trying to write a large amount of information (e.g. GBs)" — can this error also be triggered by D1 internal events (DO migration, storage backend issues) unrelated to query size?

Request IDs

Incident A (2026-04-24 ~03:20 UTC)

• 08C1QQ8B6FLVMWYC — DO tick that stalled on D1 for ~75s, then threw D1_ERROR
• Z570IYKCCRRFU53A — Next cron invocation, also stalled and threw D1_ERROR

Incident B (2026-04-24 ~06:19 UTC)

• 9f1201021a3381b8 — POST /sessions with D1_ERROR on integration settings reads
• 9f12016018a0b4a5 — GET /model-preferences with D1_ERROR
• 9f1200f44a6fd6b1 — Token write with D1_ERROR

Incident C (2026-04-26 ~01:04 UTC)

• IVNT2TKV4DPWBYPP — DO tick that completed successfully (same DO, 1ms before the stall)
• F3LHTE164LAJDE13 — DO tick that stalled on D1 for 78s (wallTimeMs: 18060), then threw D1_ERROR
• 0FTAESVP2P0Y6DLZ — SessionDO init (succeeded, no D1 dependency on this path)
• 2UYIM354P8B33MG8 — First successful tick after D1 recovery (wallTimeMs: 151)

---

Account ID and D1 database ID available to share privately with CF staff if needed for internal investigation.