A 500 error in the Email Builder is not diagnosable from the browser message alone. Please do not continue applying different repair commands yet, as that can make the installation state harder to identify.
The important next step is to capture the original exception:
Reproduce the 500 once and note the exact time.
Share the relevant error from var/logs/mautic_prod*.log and the PHP-FPM/web-server error log at that time. Please remove domains, credentials, tokens, and personal data.
Share the output of:
php bin/console doctrine:migrations:status
php bin/console about
List all non-core plugins, their versions, and how they were installed.
/s/update/schema returning 404 is not evidence that the database update failed. For Mautic 7, database migrations should be checked and run from the CLI, not through that old URL. After taking a verified database and files backup, run migrations only if the status command reports pending migrations:
The 7.1 → 7.2 update changes dependencies and frontend assets substantially. A third-party plugin that was valid for 7.1 can still cause a 500 in a builder after the core update. The stack trace will show whether this is a core issue, an incomplete ZIP deployment, a pending migration, or a plugin compatibility problem.
Also confirm that the whole 7.2 ZIP release was deployed consistently. A mixture of files from 7.1 and 7.2, or manually copied vendor/, app/, or generated asset files, is a common cause of post-update failures.
Once you post the exception trace and migration status, it should be possible to identify the actual cause rather than guessing.
