Skip to main content

​
Identify the affected database

In the Database pane, check whether the problem affects development or production. Compare this with the environment running the failing request. See Development and production databases. Check Replit Status for a matching incident. Do not infer an outage solely from a connection error.

​
“The endpoint has been disabled”

  1. Check for an outstanding billing issue or usage restriction.
  2. Open the Database pane and select the affected environment.
  3. If Unpause database is available, select it, then retry the connection.
  4. If the control is missing, check whether a manually configured DATABASE_URL points to a different database than the one shown in the pane.
Compare connection settings privately. Do not print or share the full connection string. Do not remove an intentional external-database configuration. If unpause fails, or the control is still missing, contact Support with the environment, error, and steps attempted. Repeated restarts are not a substitute for investigating a paused database.

​
Preview connects, but the published app does not

Check the published app’s production secrets and database configuration, especially after a restore or migration. Workspace secrets alone do not verify the production connection. In Publishing, review Adjust settings and the production secrets. If your app uses both DATABASE_URL and individual PostgreSQL variables, ensure they refer to the same intended database. Save and publish the intended configuration, then verify a read before testing writes. Never copy production credentials into frontend code or a public repository.

​
Tables or records are missing

First verify which database the app is reading. An empty development database or a different connection target can look like data loss. Check whether a recent migration changed table names or schema. Publishing app code does not establish that development records were copied to production. Do not run a reset, drop tables, or copy development data over production as a diagnostic step.

​
Data was deleted or overwritten

Stop avoidable writes to the affected data while evaluating recovery. A restore can replace newer data. Preserve the current state and understand the scope before confirming a recovery action.
Record the affected environment, approximate last known good time and timezone, and what changed. Check the recovery options and available history shown for that database. Retention and recovery methods depend on the database and configuration; do not assume an older timestamp is recoverable. Use the database-specific instructions in Development and production databases. Do not assume that rolling back app code also restores production data. Contact Support if you cannot identify a safe recovery path. Recovery is not guaranteed, and increasing retention cannot recreate history that was not kept.

​
Credentials may have been exposed

Remove exposed values from shared material and contact Support about rotation for managed database credentials. Plan for updating external clients and republishing configuration. Do not delete the database to rotate credentials.

​
Details for Support

Include the project URL, environment, sanitized error, time and timezone, recent migrations or restores, and checks already completed. Do not include database credentials, full connection strings, or customer records. See the support checklist.