Monitoring Liquibase with Vigilmon: Application Health, Database Connectivity, Hub API & SSL Certificate Alerts

Liquibase is the open-source database change management platform that tracks, versions, and deploys schema changes through XML, YAML, JSON, or SQL changelogs. Teams use it to coordinate schema evolution across development, staging, and production databases — ensuring every changeset is applied exactly once, in order, with rollback support when things go wrong. When a Liquibase deployment fails halfway through a changeset, the database is left in a partially-migrated state. When the DATABASECHANGELOGLOCK table deadlocks, every subsequent deployment hangs indefinitely. When your application starts before Liquibase finishes, it hits missing columns and throws 500 errors. Vigilmon gives you external visibility into every layer: application health after changesets apply, database TCP reachability, Liquibase Pro's status API, and SSL certificate expiry.

What You'll Build

• A monitor on your application's health endpoint to detect changeset-related startup failures
• A TCP monitor on your database port to catch connectivity failures that block Liquibase
• An HTTP monitor on your Liquibase Hub or status API endpoint (if applicable)
• SSL certificate monitoring for your application domain
• An alerting setup that identifies lock contention, failed changesets, and database connectivity issues

Prerequisites

• Liquibase 4.0+ (Community or Pro)
• An application that runs Liquibase on startup (Spring Boot, Quarkus, Micronaut, or a standalone job)
• Application health endpoint available at /health, /actuator/health, or equivalent
• Database TCP port accessible externally (PostgreSQL 5432, MySQL 3306, Oracle 1521, SQL Server 1433)
• A free account at vigilmon.online

Step 1: Understand How Liquibase Failures Surface

Liquibase runs changesets synchronously at startup or as a CI/CD pre-deployment step. Failures produce distinct observable patterns:

Pattern 1 — Lock table deadlock: Liquibase acquires the DATABASECHANGELOGLOCK table lock at the start of every run. If a previous deployment crashed mid-migration, the lock is never released. All subsequent deployments hang on Waiting for changelog lock... indefinitely until the lock times out or is manually released.

Pattern 2 — Changeset execution failure: A SQL error in a changeset (syntax error, foreign key violation, duplicate column) causes Liquibase to throw LiquibaseException, roll back the changeset (if supported by the database), and halt. The application fails to start.

Pattern 3 — Precondition failure: A <preConditions> block checks for table existence, column presence, or data conditions before running a changeset. When a precondition fails with HALT, the deployment stops and the application cannot start until the precondition is resolved.

Pattern 4 — Context/label mismatch: Liquibase uses contexts (e.g., --contexts=production) to filter changesets. If the wrong context is passed, required changesets are skipped, leaving the schema incomplete.

All four patterns result in the application health endpoint returning non-200 — the primary Vigilmon signal.

Step 2: Monitor the Application Health Endpoint

# Spring Boot Actuator
curl https://app.example.com/actuator/health
# Returns: {"status":"UP"}

# Micronaut health
curl https://app.example.com/health
# Returns: {"status":"UP"}

# Custom endpoint
curl https://app.example.com/api/health
# Returns: {"healthy":true}

1. Log in to Vigilmon → Add Monitor → HTTP.
2. URL: https://app.example.com/actuator/health.
3. Check interval: 60 seconds.
4. Response timeout: 30 seconds (allow for long changeset execution before declaring failure).
5. Expected status: 200.
6. Keyword: UP (Spring Boot) or healthy (custom endpoint).
7. Label: App health (post-Liquibase).
8. Click Save.

DATABASECHANGELOGLOCK timeout: By default, Liquibase waits up to 5 minutes before timing out on a held lock. Configure your health check timeout to account for this. If the lock is held, the application will not start for at least 5 minutes — set Vigilmon's response timeout to 30 seconds and trigger alerts after 2 consecutive failures to avoid false positives during normal migration windows.

Alert sensitivity: 2 consecutive failures to handle expected startup latency during large changeset batches.

Step 3: Monitor Database TCP Connectivity

Liquibase requires a JDBC connection to the target database. Without TCP connectivity, the liquibase.properties url is unreachable and the entire migration fails before a single changeset is applied:

# PostgreSQL
nc -zv db.example.com 5432

# MySQL / MariaDB
nc -zv db.example.com 3306

# Oracle Database
nc -zv db.example.com 1521

# SQL Server
nc -zv db.example.com 1433

1. Add Monitor → TCP.
2. Host: db.example.com.
3. Port: your database port (5432, 3306, 1521, or 1433).
4. Check interval: 2 minutes.
5. Response timeout: 10 seconds.
6. Label: Database TCP (Liquibase dependency).
7. Click Save.

This monitor catches:

• Database server crashes or planned maintenance reboots
• Security group / firewall rules that close the database port after a network change
• Database failovers where the new primary is on a different host
• Cloud provider maintenance that temporarily takes the database offline

Multi-database deployments: If Liquibase manages multiple databases (e.g., separate changelogs for an analytics database and a transactional database), add a TCP monitor for each database host. A failure in one database blocks that application tier's deployment independently.

Step 4: Monitor Liquibase Pro Status API (If Applicable)

Liquibase Pro and Liquibase Business include structured deployment reporting. If your team runs Liquibase as a service or integrates with a deployment orchestration API, add a health check on that endpoint:

# Example: deployment orchestration API exposing Liquibase run history
curl https://deploy.example.com/api/liquibase/status
# Returns: {"lastRun":"2026-07-03T12:00:00Z","status":"success","changesetsApplied":3}

# Liquibase Structured Logging output endpoint (if aggregated)
curl https://observability.example.com/api/deployments/liquibase/latest
# Returns deployment metadata JSON

1. Add Monitor → HTTP.
2. URL: https://deploy.example.com/api/liquibase/status.
3. Check interval: 5 minutes.
4. Expected status: 200.
5. Keyword: success or changesetsApplied.
6. Label: Liquibase deployment status.
7. Click Save.

If your team uses Liquibase community edition without a deployment API, skip this step. The application health monitor (Step 2) is the primary post-migration signal.

Step 5: Monitor SSL Certificates

Application SSL certificates must remain valid for your users and for any JDBC connections using SSL verification:

openssl s_client -connect app.example.com:443 2>/dev/null | openssl x509 -noout -dates

1. Add Monitor → SSL Certificate.
2. Domain: app.example.com.
3. Alert when expiry is within: 30 days.
4. Alert again: 14 days, 7 days, 3 days, 1 day.
5. Click Save.

For databases using SSL (e.g., PostgreSQL with sslmode=verify-full), also monitor the database TLS certificate if it's on a custom domain:

1. Add Monitor → SSL Certificate.
2. Domain: db.example.com.
3. Alert when expiry is within: 30 days.
4. Click Save.

Step 6: Configure Alerting

In Vigilmon under Settings → Notifications, set up notification channels and map monitors to runbooks:

| Monitor | Trigger | Action | |---|---|---| | App health endpoint | Non-200 or keyword missing | Check application logs; look for LiquibaseException, DATABASECHANGELOGLOCK, or precondition failures | | Database TCP | Connection refused | Check database server and security groups; verify the JDBC URL in liquibase.properties | | Liquibase status API | Non-200 or keyword missing | Deployment pipeline is down; check CI/CD logs for Liquibase run output | | SSL certificate | < 30 days to expiry | Renew; check Let's Encrypt renewal cron or ACM renewal settings |

Lock contention runbook: When the app health monitor fires and TCP is green, immediately check the DATABASECHANGELOGLOCK table:

SELECT * FROM DATABASECHANGELOGLOCK;
-- If LOCKED=TRUE and LOCKGRANTED is > 10 minutes ago, release the lock:
UPDATE DATABASECHANGELOGLOCK SET LOCKED=FALSE, LOCKGRANTED=NULL, LOCKEDBY=NULL WHERE ID=1;

Common Liquibase Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | DATABASECHANGELOGLOCK held by crashed process | App health timeout → 2 consecutive failures alert | | Changeset SQL syntax error | App health returns 503; database TCP green | | Foreign key violation in changeset | App health 503; schema left in partial state | | Precondition HALT stops migration | App health 503; check liquibase.preconditionOnError | | Wrong context passed — changesets skipped | App starts but features fail; app health may stay UP | | Database connection pool exhausted | App health 503; TCP still accepts connections | | JDBC driver version mismatch | App health 503 at startup; TCP green | | Database disk full during changeset | App health 503; database may still accept TCP connections | | SSL certificate expired | SSL monitor fires 30 days before; JDBC sslmode=verify-full fails | | Database failover to new host | TCP monitor on primary host fires; app health 503 until connection string updated | | Rollback failure leaves schema inconsistent | App health 503; requires manual intervention |

Liquibase coordinates schema change across every database environment your team operates — and when it fails, the failure mode is often silent, invisible from outside, and blocking. Vigilmon closes that gap with external health checks on the application post-migration, the database TCP port Liquibase depends on, and the SSL certificates protecting both. When a changeset deadlocks, a precondition halts, or the database goes offline mid-deployment, you'll know within 60 seconds.

Start monitoring your Liquibase deployments in under 5 minutes — register free at vigilmon.online.