What happened
On October 23, 2026, Cloudflare announced a new limit on recovery requests for D1, its database product. The D1 undelete API now accepts requests only for databases that were deleted within the last seven days. The notice presents this as a current API rule, rather than as a suggested operating practice.
The cutoff is tied to the time of deletion. Cloudflare says that an undelete request for a database deleted more than seven days earlier will fail and return an error. Put differently, the API is available only during the seven-day period following deletion; it is not described as an open-ended way to reverse a prior deletion.
Cloudflare frames the practical use case as accidental deletion. Its guidance is to submit an undelete request as soon as possible after deleting a D1 database by mistake, and no later than seven days after the deletion. The announcement also points readers to the undelete D1 database API reference for further information about that operation.
The changelog is narrowly scoped. It does not announce changes to creating a D1 database, using one in an application, or deleting one. It does not state that all deletion-related behavior has changed. The stated change is specifically an eligibility limit on requests made through the undelete API.
Nor does the notice describe an exception or an alternative path for databases outside the window. A request for a database deleted on day eight is said to fail with an error. Cloudflare does not say that support can override that result, that another API can restore the database, or that another retention period applies.
For operators, the important distinction is between noticing a deletion and acting on it. A database may be deleted accidentally, but the published recovery request must reach Cloudflare within the stated period. The announcement therefore turns the first week after a mistaken deletion into the only stated interval for using D1's undelete API.
The source provides no quantitative information about the number of undelete requests, the prior recovery period, or why Cloudflare selected seven days. It does, however, give affected teams a definite boundary: after seven days, the documented undelete request will not be accepted.
What the archive adds
We have not covered this before; it opens a new thread.
Trend signal
No supplied pattern genuinely fits this narrowly scoped recovery-policy change.
Why it matters
Database recovery can look like background operational plumbing until a deletion incident makes it urgent. Cloudflare has now made one D1 boundary explicit: undelete is not described as an indefinitely available corrective action. Teams that rely on D1 should treat the deadline as part of their incident response, not as a detail to discover after an error has sat unnoticed for a week.
This matters especially where deployment scripts, administrative tools, or AI-assisted automation can issue consequential actions quickly. A deletion succeeding and a reversal remaining available are separate conditions. Teams do not need to infer a new platform architecture from this notice, but they should make sure a mistaken deletion has an owner, is visible to the people able to respond, and is escalated before the stated window closes.
Limits and uncertainty
The changelog establishes only the seven-day eligibility limit for the D1 undelete API. It does not explain why Cloudflare introduced the limit, whether any account type or plan has different terms, or whether a successfully submitted request always restores all data. It does not describe backups, exports, retention behavior, support-assisted recovery, or options for a database deleted more than seven days earlier.
The notice also provides no history of the previous undelete behavior, no usage figures, and no reliability or recovery-time commitments. Teams should not read the change as a guarantee that every database can be recovered within seven days. The source says that requests in that period are accepted; it does not establish the outcome of every request or any recovery route after the cutoff.
Skill to build now
Add a D1 deletion-response check to the operational runbook this week. Record the deletion time, name the person or role authorized to submit an undelete request, and set an alert or escalation well before day seven. Use a non-production exercise to test whether the team can identify an accidental deletion, locate the required access, and make a decision quickly.
The useful outcome is an operational path, not an assumption about recovery. Review which automated jobs and human workflows can delete D1 databases, where their events are observed, and how the response owner learns about them. The source makes the timing constraint concrete even though it does not specify the recovery result.
Reader takeaway
D1 undelete requests now have a hard stated deadline: seven days after deletion. If a D1 database is deleted accidentally, treat recovery as an immediate operational task. A request made after that window will fail, and Cloudflare's changelog does not describe an alternative recovery path.
Open question
What recovery options, if any, remain for D1 databases after the seven-day undelete window expires?