Inventory all uses of the full database username, including staging sites, cron tasks and external tools. Back up protected configuration files and plan a short maintenance window if the application cannot switch credentials without interruption.

1. Open Hosting Features > MySQL > Users and identify the exact user.
2. Choose its pencil action and enter a newly generated unique password in the password and confirmation fields. Save the change.
3. Update each application’s supported secret or configuration store immediately. Preserve the correct quoting or escaping syntax and avoid printing credentials into logs.
4. Reload application configuration or restart supported workers if they cache credentials. Test a read operation and a harmless write through the application.
5. Verify scheduled jobs at their next run, then remove obsolete password copies from deployment notes or unused configuration backups.

The application and its background jobs should connect with the new secret. Check error logs for repeated authentication failures after interactive pages appear healthy.

If one client fails, confirm its full username, connection host and configuration cache. A forgotten staging installation can keep retrying the old secret. Restore service through a controlled credential update rather than deleting and recreating the database.

No. Database users and the control-panel identity are separate. Change each credential through its own supported management screen when responding to a wider account compromise.

• Creating a SiteWorx database and restricted application user
• Scheduling a SiteWorx cron task with useful output
• Following SiteWorx web-server logs during a reproducible error
• Opening phpMyAdmin from SiteWorx for the correct database

• InterWorx: Add Edit Delete MySQL Users