> ## Documentation Index
> Fetch the complete documentation index at: https://docs.replit.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Troubleshoot databases

> Safely investigate database connection failures, paused endpoints, missing production data, and recovery options without deleting or overwriting your data.

## 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](/features/data-and-storage/development-and-production).

Check [Replit Status](https://status.replit.com) 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

<Warning>
  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.
</Warning>

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](/features/data-and-storage/development-and-production).
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](/help/troubleshooting/overview#when-to-contact-support).