Skip to content

wp_db_table_crashed

Severity: Critical Signal: db_table_crashed — MySQL table crash detected

What this signal means

A MySQL table is marked as crashed. Queries against that table are failing, causing errors on any page that reads from or writes to it.

What surprise this prevents

Data writes silently failing and pages partially breaking — errors that look like application bugs until the crashed table is identified.

Why it matters

A crashed table causes functional failures. If it is a core WordPress table (e.g. wp_options, wp_posts, wp_users), the site may be partially or fully broken. Writes to a crashed table silently fail, which can cause data loss.

Investigate

View entity alerts in Logystera →

Check:

  • payload.error — which table is crashed? Look for the table name in the MySQL error string (e.g. Table 'wp_options' is marked as crashed).
  • When did this start? Was there a spike in traffic or a failed update around that time?

  1. Identify the crashed table from the error message.

  2. Repair the table using MySQL directly (if you have server access): sql REPAIR TABLE wp_options; Or repair all WordPress tables at once: sql REPAIR TABLE wp_options, wp_posts, wp_postmeta, wp_users, wp_usermeta, wp_comments, wp_commentmeta, wp_terms, wp_term_relationships, wp_term_taxonomy;

  3. Repair from WordPress admin (if the site is partially accessible): Add to wp-config.php: php define( 'WP_ALLOW_REPAIR', true ); Then visit: https://yoursite.com/wp-admin/maint/repair.php Remove this line after repair.

  4. Using WP-CLI: bash wp db repair

  5. On shared hosting: Use phpMyAdmin. Select your database, check the table in question, choose Repair table from the dropdown.

  6. If repair fails, restore from your most recent database backup.

  7. After repair, investigate root cause:

  8. Table crashes are often caused by unclean MySQL shutdowns (server crash, power loss).
  9. Frequent crashes on the same table can indicate disk issues. Contact your host.

When to safely ignore

This alert does not have a safe-to-ignore case. A crashed table requires repair. The only question is urgency: if the crashed table is not used by a user-facing feature, you have a short window to repair it before it causes visible failures.

Signal reference

{
  "event_type": "db_table_crashed",
  "payload": {
    "error": "Table 'wp_options' is marked as crashed and should be repaired",
    "query_hash": "d4e5f6a7"
  }
}