Deleted a Cloudflare D1 Database? You Have 7 Days to Recover It
Workers Paid keeps 30 days of D1 Time Travel, so the database you deleted yesterday looks safe. Once you undelete it, how far back can you actually restore?
- Request D1 undeletion within 168 hours of deleting the database.
- Time Travel retains 30 days on Workers Paid and seven on Free; that is a different recovery window.
- After undeletion, Time Travel cannot reach a state at or before the recovery operation.
A paid plan does not buy a longer undelete window
If the D1 database itself is gone, request undeletion within seven days. Cloudflare’s October 23 update says undelete requests fail once seven days have passed since deletion. The API reference defines the interval as seven times 24 hours. Finding the mistake later does not restart that clock.
The familiar 30-day figure belongs to Time Travel on Workers Paid. It describes retained database history, not how long a deleted resource remains recoverable.
A bad DELETE query and a deleted database need different tools
Time Travel can reverse a bad migration or an unintended SQL change while the database still exists. It is enabled automatically. Undelete addresses removal of the database resource.
| Situation | Recovery path | Boundary |
|---|---|---|
| Rows or schema changed incorrectly | Time Travel | 30 days on Paid; seven on Free. |
| The database resource was deleted | Undelete API | Request within seven days of deletion. |
| You want an old bookmark after undeletion | That Time Travel restore is unavailable | Only states after undeletion can be restored. |
A Time Travel restore replaces the existing database contents and cancels queries in flight. Treat choosing a timestamp as a decision about current data, not as opening a read-only historical view.
Recover the original UUID, then handle any name conflict
The endpoint takes an account identifier and the deleted database’s UUID:
POST /accounts/ACCOUNT_ID/d1/database/DATABASE_ID/undeleteThe API base is https://api.cloudflare.com/client/v4, with API-token authentication supported. A practical starting point is the database ID retained in deployment configuration. Check it against the deleted resource rather than substituting a newly created database with the same name.
Undeletion normally restores the former name. If another database already occupies it, supply new_name in the request body. The recovered database counts toward account limits, so capacity and naming can matter even when the request is timely.
Recovering the resource does not recover its old Time Travel access
Once undeletion finishes, bookmarks and timestamps at or before that operation cannot be restored. This matters if a destructive query preceded deletion: bringing the resource back does not also provide a Time Travel route to the earlier good state.
For longer retention, D1 supports SQL export and import. An export blocks other database requests while running, and databases containing virtual tables have export restrictions. A separate copy therefore needs a retention and restore plan suited to the database.
During an actual deletion incident, submit the undelete request before the seven-day window closes. After recovery, verify the data you need and decide which separate copies should survive the next mistake.