In the web app's sidebar, select Database Changes under Monitor. Every reported deployment operation is listed. Use the Status dropdown to filter to Failure, or find the run with the Filter operations search bar and the Date column.

If the operation you expected is not in the list at all, reporting itself did not happen. Follow Investigate an unattributed operation to check the reporting configuration in that environment.

Select the operation to open its detail page. The header shows the command, the failure status, and the operation id. The Outcome Breakdown card summarizes the run as four counts: Run, Previously run, Filtered out, and Failed deployment, with a caption showing how many changesets were evaluated.

This is also the state of your database. An update that fails partway is not all-or-nothing. Changesets counted as Run are deployed and recorded in the DATABASECHANGELOG table. The failed changeset and everything after it are not. The database is in a known, tracked, intermediate state, which is what makes both recovery paths safe.

In the Changesets section, open the Failed tab. It is marked when the run contains a failure, and each row shows the changeset as filepath :: changesetId :: author with the failure reason underneath.

The Not deployed tab lists the changesets that never ran because the failure ended the operation. The Run tab lists what deployed before the failure.

The Messages & Analysis section shows the operation's error and warning messages, with the failing error in a marked card. For the full context around it, open Execution Logs at the bottom of the page. The error is usually the answer: a SQL error from the database, a precondition failure, or a checksum validation error.

If you ran the operation with --reports-enabled, select View Report in the header to open the Liquibase HTML report. If AI analysis is enabled for your workspace, Analyze issues generates a diagnosis of the failure.

Fix forward: Correct the failing changeset and rerun update through the same pipeline. Liquibase deploys only what has not run, so the changesets that already deployed are not repeated.

Roll back: Restore the previous state with your rollback scripts, then correct the change before it deploys again.

The trade-offs are their own decision. See Decide whether to roll back or fix forward.

Rerun the deployment through the same pipeline and confirm the new operation reports success in Database Changes. The failed operation stays in the history. That record is your audit trail of the incident and the fix.