Catch the change nobody filed a ticket for
Compare and Sync is something you run. Drift Monitor is something that runs. The Executor takes schema snapshots on a schedule, diffs them against a baseline, and records added, modified, and removed objects as events you can acknowledge, resolve, or restore from.
Snapshots, not a live tail of every DDL statement
Set a baseline
Pick a connection and database. The first snapshot is the shape you consider correct. System schemas can be excluded so vendor objects do not swamp the feed.
Schedule on the Executor
A cron expression and timezone live on the monitor config. The Executor ticks once a minute and runs due snapshots locally the cloud control plane does not reach into your database to poll.
Review the event
Open drift shows added, modified, and removed objects. Acknowledge or resolve it, and generate a restore script with the same SQL risk hints used on change scripts.
Scheduled work, plus a snapshot after you deploy
Scheduled
The cron you configured. Use this to notice hotfixes, forgotten index changes, and restores that silently diverged from the last known good schema.
After a change script
A post-execution snapshot records the schema the pipeline just produced, so later drift is measured against what Migratrix itself deployed, not against last Tuesday's guess.
What is built, and what is not
This is schema drift, not data drift
The monitor snapshots structure. Row-level drift is a Compare & Sync job you run on selected tables, not a scheduled monitor today.
Alert routing is not a finished notification product
Each monitor can store which users should be alerted. Do not plan on Slack or email dispatch from Drift Monitor as a guaranteed delivery path until we walk through it with you. The durable part is the event list, acknowledge/resolve workflow, and restore script in the product.
It is part of the Growth plan
Drift Monitor is included from the Growth plan. Compare, pipelines and Explorer are available on every plan.
What you set when you create a monitor
| Field | Default |
|---|---|
| Schedule | Five-field cron, UTC. Presets: every hour, every 6 hours, every 12 hours, daily at midnight, weekly on Monday. The shipped default is hourly. |
| Timeout | 300 seconds per snapshot run. |
| Retention | Keep the last 30 snapshots. |
| Exclude system schemas | On. Vendor catalogues stay out of the event feed. |
| Enabled | On when created. You can disable a monitor without deleting it. |
| Where snapshots live | In a _migratrix schema on the monitored database, on the Executor side not in the Migratrix cloud. |
| Who can create one | Schema admin on that environment. The connection list is already filtered to environments you can administer. |
Open, acknowledged, resolved and three ways a snapshot starts
Scheduled
The cron fired. Unexpected objects show as Open until someone acknowledges or resolves them.
Manual
Run a snapshot now, without waiting for the hour. Same diff, same event workflow.
After a deploy
A post-change-script snapshot is labelled “deploy” in the UI. Those events are created already Resolved, because the baseline is supposed to move with a governed change.
Restore script
Generate DDL to put the baseline back, with a risk level and warnings in the same style as a change script. Copy it; it does not auto-execute against production.