Monitoring Flyway with Vigilmon: Migration Health, Database Connectivity, Application Uptime & SSL Certificate Alerts

Flyway is the version-controlled database migration tool that thousands of teams rely on to evolve schemas safely — applying versioned SQL scripts in order, validating checksums, and tracking applied migrations in the flyway_schema_history table. When a Flyway migration runs during a deployment and the underlying database is unreachable, the deployment fails silently. When a migration script has a syntax error, the application startup blocks until a timeout is hit. When the database connection pool is exhausted after a large schema change, the application returns 500 errors to users. Vigilmon gives you external visibility into the whole Flyway deployment cycle: application health after migrations complete, database TCP connectivity, migration-triggered webhook endpoints, and SSL certificate expiry.

What You'll Build

• A monitor on your application's health endpoint to detect migration-related startup failures
• A TCP monitor on your database port to catch connectivity issues that block Flyway
• An HTTP monitor on a migration-status webhook endpoint (if your CI/CD exposes one)
• SSL certificate monitoring for your application domain
• An alerting setup that correlates deployment timing with application health failures

Prerequisites

• Flyway 7.0+ (Community, Teams, or Enterprise)
• A deployed application that runs Flyway migrations on startup (Spring Boot, Quarkus, or a standalone migration job)
• Your application exposes a health endpoint (e.g., /health, /actuator/health, or /api/health)
• Database port accessible via TCP from external monitoring (PostgreSQL 5432, MySQL 3306, SQL Server 1433)
• A free account at vigilmon.online

Step 1: Understand How Flyway Failures Surface

Flyway migrations run synchronously at application startup or as a pre-deployment job. Failures surface in three patterns:

Pattern 1 — Application startup blocked: Flyway attempts to connect to the database, the connection times out, and the application JVM stays up but health checks return unhealthy. GET /actuator/health returns HTTP 503.

Pattern 2 — Migration script failure: Flyway detects a checksum mismatch or SQL syntax error, marks the migration as FAILED in flyway_schema_history, and throws FlywayException. Spring Boot with spring.flyway.enabled=true fails the startup context — /actuator/health/liveness returns DOWN.

Pattern 3 — Schema lock contention: On high-traffic deploys, the flyway_schema_history table lock is held by a previous migration, blocking new application instances indefinitely until the lock times out.

All three patterns result in your application health endpoint returning a non-200 response — the primary signal Vigilmon monitors.

Step 2: Monitor the Application Health Endpoint

The most critical Flyway monitoring signal is the application health endpoint immediately after a deployment:

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

# Quarkus
curl https://app.example.com/q/health/ready
# Returns: {"status":"UP","checks":[...]}

# Custom health endpoint
curl https://app.example.com/health
# Returns: {"status":"ok"}

1. Log in to Vigilmon → Add Monitor → HTTP.
2. URL: https://app.example.com/actuator/health (or your equivalent).
3. Check interval: 60 seconds.
4. Response timeout: 30 seconds (migrations can make startup slow — allow enough time before declaring failure).
5. Expected status: 200.
6. Keyword: UP (Spring Boot) or ok (custom endpoint).
7. Label: App health (post-Flyway).
8. Click Save.

Why 30-second timeout? Flyway migrations on large tables (e.g., adding an index to a 100M-row table) can take minutes. During this time, the application is starting but not yet healthy. A 30-second response timeout prevents false positives during expected migration windows, while still catching true connectivity failures that never resolve.

Alert sensitivity: Trigger after 2 consecutive failures to avoid alerting on a single slow migration that completes on the next check.

Step 3: Monitor Database TCP Connectivity

Flyway requires a direct TCP connection to the database. If the database port is unreachable — due to a security group rule change, a database restart, or a network partition — Flyway cannot run migrations and the application will not start:

# Test PostgreSQL connectivity
nc -zv db.example.com 5432

# Test MySQL connectivity
nc -zv db.example.com 3306

1. Add Monitor → TCP.
2. Host: db.example.com (or your database hostname).
3. Port: 5432 (PostgreSQL), 3306 (MySQL), 1433 (SQL Server), or 5432 (CockroachDB).
4. Check interval: 2 minutes.
5. Response timeout: 10 seconds.
6. Label: Database TCP (Flyway dependency).
7. Click Save.

This monitor catches:

• Database server restarts or crashes
• Security group / firewall rule changes that accidentally close the database port
• Network partitions between the application subnet and the database subnet
• Database maintenance windows that were not communicated to on-call

RDS and Cloud Databases: If you use Amazon RDS, Cloud SQL, or Azure Database, the database endpoint may change during a failover. Monitor the CNAME endpoint (e.g., mydb.cluster-xyz.us-east-1.rds.amazonaws.com) so the monitor follows the failover automatically.

Step 4: Monitor a Migration-Status Webhook (CI/CD Integration)

If your CI/CD pipeline triggers Flyway as a pre-deployment step and exposes a migration status endpoint, Vigilmon can verify the webhook receiver is reachable before migrations run:

# Example: a deployment pipeline webhook receiver
curl -X GET https://deployments.example.com/api/migration-status/latest
# Returns: {"status":"completed","version":"V42__add_user_preferences.sql"}

For teams using Flyway Teams or Enterprise with the Flyway API server mode:

# Flyway Teams API (if running as a service)
curl http://flyway-server:8080/api/flyway/info
# Returns migration history JSON

1. Add Monitor → HTTP.
2. URL: https://deployments.example.com/api/migration-status/latest (your endpoint).
3. Check interval: 5 minutes.
4. Expected status: 200.
5. Keyword: completed or version.
6. Label: Flyway migration webhook.
7. Click Save.

If you do not have a dedicated migration status endpoint, skip this step and rely on the application health monitor (Step 2) as your post-migration signal.

Step 5: Monitor SSL Certificates

Your application domain's SSL certificate must be valid for both end users and for Flyway's JDBC connections when using SSL-encrypted database connections (e.g., jdbc:postgresql://db.example.com:5432/mydb?ssl=true):

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.

If your database uses SSL certificates (e.g., RDS with rds-ca-2019), those are managed by the cloud provider and rotated automatically — focus SSL monitoring on your application's public-facing domain.

Step 6: Configure Alerting for Deployment Correlation

In Vigilmon under Settings → Notifications, configure alert channels and customize the alert message to include deployment context:

| Monitor | Trigger | Action | |---|---|---| | App health endpoint | Non-200 or keyword missing | Check application logs for FlywayException; verify flyway_schema_history for FAILED entries | | Database TCP | Connection refused or timeout | Check database server status; verify security group rules; check RDS instance state | | Migration webhook | Non-200 or keyword missing | CI/CD webhook receiver is down; deployment pipeline may be stuck | | SSL certificate | < 30 days to expiry | Renew certificate; check Let's Encrypt or ACM auto-renewal configuration |

Deployment alerting pattern: Suppress the application health monitor during the first 5 minutes of a deployment window (use Vigilmon's maintenance window feature), then re-enable it. Any failure after that window is a genuine migration problem, not expected startup latency.

Common Flyway Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Database unreachable during deployment | TCP monitor fires; app health never recovers | | Migration script SQL error | App health returns 503; TCP monitor stays green | | Checksum mismatch (file edited post-apply) | App health returns 503 at every restart | | Schema lock contention on concurrent deploy | App health slow/timeout; resolves when lock clears | | Out-of-order migration applied | FlywayException at startup; app health 503 | | Database credentials rotated without updating app config | TCP monitor green; app health 503 (auth failure) | | Missing migration file on rolling deploy | Some instances healthy, some unhealthy — health monitor catches unhealthy instances | | Database disk full during large migration | TCP green; app health 503; migration partially applied | | SSL certificate expired | SSL monitor fires 30 days before; JDBC SSL connections fail at expiry | | Network partition isolating DB subnet | TCP monitor fires; app health degrades |

Flyway makes database schema evolution predictable — but the moment the database is unreachable, credentials are wrong, or a migration script has an error, your deployment fails in ways that are not visible from the outside. Vigilmon closes that gap with external health checks that monitor application uptime, database TCP reachability, and SSL certificate validity across every Flyway deployment, so you know within 60 seconds when a migration has gone wrong and your application is not starting cleanly.

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