The problem
After an unclean shutdown or a full disk, a MyISAM table can end up crashed: the site it belongs to throws database errors while everything else works, so server-level monitoring sees nothing wrong. Grepping the MySQL error log is misleading too — repaired tables keep their old crash entries forever.
The solution
VpsMonitor.Pro runs a live CHECK TABLE across databases on a schedule — the actual source of truth, not the historical log — and grades the result. A crashed table turns the MySQL tile red, names the exact database and table, and fires an alert.
The same view lists all remaining MyISAM tables per database (the engine that crashes; InnoDB recovers itself), which doubles as a migration to-do list. A repair action is one click away, and after it runs the check goes green again — confirmation the fix actually worked, not just hope.
Pair it with the disk checks: most table crashes on shared servers trace back to a disk that briefly hit 100%.
Frequently asked questions
Why do MyISAM tables crash but InnoDB tables don’t?
MyISAM has no crash recovery — an interrupted write corrupts the table until repaired. InnoDB replays its transaction log on startup and heals itself, which is why migrating busy tables to InnoDB is the long-term fix.
Is REPAIR TABLE safe to run?
Generally yes for MyISAM, though it can take time on big tables and rare edge cases lose rows — which is why detection-plus-deliberate-repair beats blind automation.
How fast will I know a table crashed?
The check runs every few hours and can be run on demand; with the red-check email alert you typically know before the site owner does.
Get a license · Download free — 7-day trial