POST Repair Database Indexes
Add any missing critical indexes.
The work runs inline, not in the background, so on a large site the request can take a while. The ALTERs are idempotent and prefer a non-blocking online build.
Three of the outcomes are 200 responses and only one of them means work was done — check the flags before reporting success:
| Condition | Response |
|---|---|
| Nothing was broken | 200, “All database indexes are healthy.” No repaired key. |
| Another repair is in flight | 200 with pending: true. Deliberately not an error — a second tab is already doing the work. |
| Repair succeeded | 200 with repaired listing the index names that were added. |
| Repair failed | 422 with failed, usually insufficient database privileges. |
A five-minute transient lock prevents concurrent admin tabs from stacking overlapping ALTER statements on the same tables.
Required capability: fcrm_manage_settings
Enforced by SettingsPolicy::verifyRequest(), the policy default for this route group.
Authorizations
WordPress Application Passwords — use Basic auth with your WordPress username and an application password in the format: username:application_password
Responses
Repair finished, was unnecessary, or is already running.