Monitoring Atlas with Vigilmon: Cloud Dashboard, CI/CD Webhooks, Schema Migration Health & SSL Certificate Alerts

Atlas is the modern database schema management tool from Ariga that treats database schema as code — letting teams declare the desired schema state and have Atlas automatically plan, lint, and apply the migration diff. Atlas Cloud provides a hosted control plane for schema versioning, CI/CD integration, and migration history. When Atlas Cloud is unavailable, CI/CD pipelines that push schema changes cannot validate migrations before deployment. When an Atlas migration fails mid-apply, the database schema drifts from the declared state. When the application starts against an incompatible schema, it throws errors on every request. Vigilmon gives you external visibility into Atlas Cloud availability, CI/CD webhook endpoints, application health after migrations, and SSL certificate expiry.

What You'll Build

• A monitor on Atlas Cloud to detect portal and API unavailability
• A TCP monitor on your database port to catch connectivity issues that block Atlas
• An HTTP monitor on your application health endpoint post-migration
• An HTTP monitor on your Atlas CI/CD webhook receiver (if applicable)
• SSL certificate monitoring for your Atlas Cloud domain and application

Prerequisites

• Atlas 0.10+ (Community or Cloud)
• Atlas Cloud account at atlasgo.cloud (for cloud monitoring steps)
• Application exposing a health endpoint after schema migrations
• Database accessible via TCP (PostgreSQL 5432, MySQL 3306, SQLite is local-only)
• A free account at vigilmon.online

Step 1: Understand Atlas Migration Failure Modes

Atlas applies schema changes using atlas schema apply or atlas migrate apply, with automatic drift detection between the current schema and the desired state. Failures appear in three patterns:

Pattern 1 — Atlas Cloud API unavailable: When Atlas Cloud is down, atlas migrate push cannot publish migration files, and atlas migrate apply --env cloud cannot fetch the target migration version. CI/CD pipelines that depend on Atlas Cloud fail before any database changes are attempted.

Pattern 2 — Database unreachable during apply: Atlas establishes a direct database connection at the start of every migration run. If the TCP connection fails, Atlas exits with a connection error and the schema remains unchanged.

Pattern 3 — Migration lint failure blocking CI: Atlas Cloud's CI/CD integration runs atlas migrate lint on every pull request. If the lint check API is unavailable, the GitHub Actions step times out and blocks the PR merge, even when the migration SQL is perfectly valid.

Pattern 4 — Schema drift between apply and application startup: Atlas applies changes asynchronously as a pre-deployment step. If the application starts before Atlas completes (race condition in a deployment pipeline), it encounters the old schema and throws ORM mapping errors.

Step 2: Monitor Atlas Cloud Portal Availability

Atlas Cloud hosts your migration history, schema registry, and CI/CD integration. When the portal is unavailable, teams cannot inspect migration state, and CI pipelines cannot validate changes:

curl https://atlasgo.cloud
# Returns HTML with Atlas Cloud dashboard content

1. Log in to Vigilmon → Add Monitor → HTTP.
2. URL: https://atlasgo.cloud.
3. Check interval: 5 minutes.
4. Response timeout: 15 seconds.
5. Expected status: 200.
6. Keyword: Atlas (present in Atlas Cloud page content).
7. Label: Atlas Cloud portal.
8. Click Save.

Self-hosted Atlas: If your team runs Atlas in fully self-hosted mode without Atlas Cloud, skip this step and rely on the database TCP monitor (Step 3) and application health monitor (Step 4) as your primary signals.

Step 3: Monitor Database TCP Connectivity

Atlas requires a direct TCP connection to the target database to inspect schema state and apply migrations. A closed database port blocks every Atlas operation:

# PostgreSQL
nc -zv db.example.com 5432

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

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

# CockroachDB
nc -zv db.example.com 26257

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

This monitor catches:

• Database server crashes or maintenance restarts
• VPC security group changes that close the database port
• Cloud provider database failovers that momentarily drop TCP connections
• Network partitions between the Atlas migration runner and the database subnet

Step 4: Monitor Application Health After Atlas Migrations

The clearest signal that an Atlas migration succeeded and the application is operating correctly is the application health endpoint responding with a healthy status:

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

# Node.js / Express
curl https://app.example.com/health
# Returns: {"status":"ok"}

# Django / FastAPI
curl https://app.example.com/api/health
# Returns: {"healthy":true,"database":"connected"}

1. Add Monitor → HTTP.
2. URL: https://app.example.com/health.
3. Check interval: 60 seconds.
4. Response timeout: 20 seconds.
5. Expected status: 200.
6. Keyword: ok or UP.
7. Label: App health (post-Atlas migration).
8. Click Save.

Schema drift detection: If Atlas applies migrations but the application ORM mapping is not updated to match the new schema, the health endpoint may return 200 while individual API endpoints return 500 errors. Complement the health check with an API smoke test on a critical endpoint that exercises database reads.

Step 5: Monitor Atlas CI/CD Webhook Receiver

Atlas Cloud integrates with GitHub Actions, GitLab CI, and other CI/CD systems through webhook callbacks that report migration plan status. If your team runs a webhook receiver that accepts Atlas migration events, monitor its availability:

# Atlas migration event webhook receiver
curl https://deployments.example.com/api/atlas/webhook
# Returns: 200 OK (receiver is ready to accept Atlas events)

# Atlas schema lint result endpoint
curl https://ci.example.com/api/atlas/lint-status/latest
# Returns: {"status":"passed","checksRun":12}

1. Add Monitor → HTTP.
2. URL: https://deployments.example.com/api/atlas/webhook (your endpoint).
3. Check interval: 5 minutes.
4. Expected status: 200.
5. Label: Atlas CI webhook receiver.
6. Click Save.

If you use Atlas Cloud's built-in GitHub App for CI/CD integration (no self-hosted webhook receiver), this step is not needed — the Atlas Cloud portal monitor (Step 2) covers that dependency.

Step 6: Monitor SSL Certificates

Atlas Cloud uses HTTPS for all API calls from the atlas CLI. Your application domain must also have a valid SSL certificate:

# Check Atlas Cloud certificate (informational — Ariga manages this)
openssl s_client -connect atlasgo.cloud:443 2>/dev/null | openssl x509 -noout -dates

# Check your application certificate
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 Atlas CLI calls Atlas Cloud with a --token and your CI runner uses a self-signed certificate for internal services, add a monitor for the internal CI domain as well.

Step 7: Configure Alerting

In Vigilmon under Settings → Notifications, connect your Slack, PagerDuty, or email channel and map monitors to specific runbooks:

| Monitor | Trigger | Action | |---|---|---| | Atlas Cloud portal | Non-200 or keyword missing | Check status.atlasgo.cloud; delay migrations requiring Atlas Cloud; use atlas migrate apply in local mode | | Database TCP | Connection refused | Check database server status; verify security group rules; inspect cloud provider console | | App health (post-migration) | Non-200 or keyword missing | Check for schema drift with atlas schema diff; inspect app logs for ORM errors | | Atlas CI webhook | Non-200 | CI pipeline blocked; check webhook receiver logs; Atlas lint checks cannot report status | | SSL certificate | < 30 days to expiry | Renew certificate; check Let's Encrypt renewal job or ACM managed certificate |

Schema drift runbook: When the app health monitor fires after a deployment and TCP is green, run:

# Inspect current database schema vs. Atlas-managed desired state
atlas schema diff \
  --from "postgresql://user:pass@db.example.com:5432/mydb" \
  --to "file://schema.hcl"

If drift is detected, atlas schema apply will generate and apply the corrective migration.

Common Atlas Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Atlas Cloud API down during CI pipeline | Atlas Cloud portal monitor fires; lint checks block PRs | | Database port closed by security group change | TCP monitor fires; Atlas apply fails at connection | | Application starts before Atlas migration completes | App health 503 on first check; clears when migration finishes | | Schema drift — manual DB change not in Atlas state | App health degraded; atlas schema diff shows drift | | Atlas migrate apply fails on constraint violation | App health 503; schema in partial state; check Atlas migration logs | | Atlas Cloud token expired — CLI auth fails | App health unaffected; CI/CD pipeline fails at atlas migrate push | | TLS certificate mismatch in Atlas Cloud CLI call | Atlas CLI exits with TLS error; CI pipeline fails; App health unaffected | | DNS change pointing database hostname to wrong host | TCP monitor fires on new IP; Atlas cannot connect | | Concurrent migrations from two deploy replicas | Atlas advisory lock prevents double-apply; one process blocks; app health may timeout | | Cloud database maintenance window | TCP monitor fires for duration; Atlas auto-retries on reconnect |

Atlas brings the declarative infrastructure-as-code philosophy to database schemas — but when Atlas Cloud is unavailable, the database is unreachable, or a migration applies a breaking schema change, your application fails in ways that are invisible from the outside. Vigilmon wraps every layer with external monitoring: Atlas Cloud portal availability, database TCP reachability, application health after migrations, and SSL certificate expiry — so you catch Atlas-related failures within 60 seconds and restore schema integrity before users experience errors.

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