Before the wrong change.A way back to your data.

A wrong update can take seconds. Finding the recovery action should not take longer than understanding the mistake. In Fortly, open your project’s Database workspace, choose Backups, and select Point in time. The picker shows the available recovery window for that database, rather than a generic calendar that offers dates you cannot use. Quick picks cover recent moments; an exact date lets you work backwards from when a change happened.

Every plan receives continuous PostgreSQL backups. Changes are archived within about a minute, encrypted, to storage in a different region, and retained for seven days. The earliest selectable moment also depends on when the database was created and the backups that are available. Daily backup shortcuts are useful landmarks, but recovery is not restricted to those daily timestamps. Choose a target inside the server’s displayed window.

The confirmation keeps the project, full date and timezone together. Review them before starting, particularly when an incident report uses UTC and your browser shows local time. The owner or an admin can start recovery. Project access alone does not grant the authority to replace a database.

After the request is accepted, the console shows the actual recovery states: waiting for the service, rebuilding from backups and switching the project over. You can leave the page; the service continues the operation. An accepted request is not a completed restore, and the status stays available when you return. Fortly emails the person who started the restore when it completes or fails.

Your current database remains in use while the replacement is being prepared. At switch-over, the project starts using the recovered database and connections reopen on that data. Writes after the selected moment are replaced, including writes made while recovery was running. Pause application writers before starting if your recovery procedure needs to prevent those additional writes. Only one restore can be active per project; another request is refused until it finishes.

Once recovery completes, inspect important records and review API permissions. Your deployed code is unchanged. If a migration changed the schema, verify that the current release works with the restored database, or select a compatible application release separately.

The database replaced by the latest restore is retained for seven days after completion. Undo switches the project back to that previous database, after a confirmation describing the change. The console shows when the previous copy expires, so the recovery decision has a visible deadline. Only the latest eligible restore can be undone; Undo is not an unlimited toggle through older database versions.

Pro and Max include point-in-time restore. Free accounts can try it through December 1, 2026, UTC, with one non-failed restore per project in a rolling 24-hour window. The offer ends at 00:00 UTC on December 2. Undo does not consume an additional restore, and it does not refund the restore already started. Exports and file imports remain available on every plan.

PostgreSQL recovery does not restore project files, KV namespaces, deployments, secrets, schedules or email settings. Deleting a project also removes its retained database copies. Keep exports and migration files for the retention or portability requirements your team has, and rehearse the recovery procedure before an incident. The recovery guide and Restores API explain the exact status fields, errors and retry behavior.

Open the detailed guide for configuration examples, access requirements, limits and troubleshooting. Then use your own project to verify the full flow before depending on it in production.

Read the recovery guide · Explore the full platform