After an update, the answer to whether it worked exists in three places. The command's exit code is what your pipeline branches on. The DATABASECHANGELOG table records what is deployed in the target database itself. If reporting is configured, the operation also appears in the dashboards.

The exit code

update exits 0 on success and nonzero on failure. This is the signal automation acts on. A failed changeset stops the run, so later changesets are not attempted.

The command output ends with an update summary that counts what happened to each changeset. It ran, was previously run, was filtered out by labels or contexts, or failed. The same buckets appear as the outcome pills in the dashboards.

The tracking table

Liquibase records each deployed changeset as a row in the DATABASECHANGELOG table, including its id, author, and checksum. The table is the database's own record of what has been applied. Query it when you need ground truth for one database. See What is the DATABASECHANGELOG table?. The DATABASECHANGELOGHISTORY table additionally records operations that DATABASECHANGELOG does not keep. See What is the DATABASECHANGELOGHISTORY table?.

Reports and dashboards

With --reports-enabled, update produces an HTML report of what happened. See What is the update report?.

With operation reporting configured, the run also appears in View database deployments, attributed to its changelog and connection. Each deployment row carries a status and a set of Outcome pills that break down its changesets. Run, Previously run, Filtered out, and Failed deployment. A dash in the Outcome column means the operation carries no update summary, not that it failed.

When status says failure

Open the failed operation's details page. The Failed tab under Changesets lists the changesets that errored, with the failure reason where it is available. The Not deployed tab lists the ones that were skipped because the run stopped. The execution logs carry the error, timestamped. Continue in Investigate a failed deployment.