Separate the website from the control panel
Find the matching error for one failing request before changing PHP settings or replacing site files.
A 500 identifies a failed request, so use its time and URL to locate the matching application or web error. A PHP fatal error, application exception, malformed web-server directive or unavailable upstream process may all surface as 500. First identify whether the failing URL is the public website or the DirectAdmin control panel. This guide concerns the hosted website. A panel-wide 500, or several unrelated customer sites failing together, belongs with the hosting operator promptly.
Write down the exact hostname, path, time, request method if known and whether the issue began after a deployment or PHP change. Test one other page on the same domain and, if you manage one, a static text file. A static file loading while a PHP page fails is useful evidence, not proof that the PHP version alone is wrong.
Preserve the evidence and recovery route
Check whether a verified backup and a copy of the last working application release are available. Stop repeated automated jobs or form submissions only if they are causing duplicate side effects and you have authority to do so. Avoid displaying detailed stack traces to public visitors; retrieve errors through access-controlled logs. Note any plugin update, dependency install, database migration, environment change or resource limit alert near the first failure.
Do not change PHP versions, file permissions, database settings and rewrite rules together. A single controlled adjustment is easier to verify and reverse. If the service is critical or the failure involves payment or data writes, contact the application owner and host before experimenting in production.
Find the log entry for this request
Use the account’s available log viewer, or ask support for the domain’s web and PHP error entries around the timestamp. DirectAdmin documents domain-specific web logs and PHP-FPM configuration, but the actual file path and visibility depend on the server stack and customer permissions. Read a few lines before and after the matching error. If no entry appears, check that the request reached this server and whether a proxy, CDN or other application layer generated the 500.
Examples of useful distinctions are: a PHP fatal error naming a script and line; an upstream or PHP-FPM connection error; a web-server syntax error after an .htaccess edit; or a database connection exception. Each requires a different owner and remedy. Redact tokens, passwords, session values and personal data from any excerpt sent to support.
Choose a reversible response from the evidence
If the log names a new plugin or code path, compare it with the last working release and use the application vendor’s supported rollback or staging fix. If it shows a missing PHP extension or incompatible syntax, check the current web runtime, application requirements and offered PHP versions. The command-line version may differ from the site’s web handler. Use the related PHP-change guide to test a version switch; do not jump to an end-of-life runtime merely to silence an error.
If the log points to a changed .htaccess directive, restore the previous verified file and retest. If PHP-FPM or the web server is unavailable, or several accounts fail, ask the host to inspect service health and capacity. Customers should not restart shared services or change server-wide limits. A database failure needs a separate check of connection details, availability and recent migrations; never paste credentials into a ticket.
For example, static files loading while one PHP page fails after a plugin change narrows the fault, but does not prove that plugin caused it. Use the matching error and a reversible application test before changing PHP globally.
Confirm recovery beyond the homepage
After one change, reload the original URL and a static page, then inspect the log for a fresh error. Test the application journey that failed: login, form submission, API call or scheduled job as applicable. Confirm that a “fixed” page is not merely a cached copy or a maintenance placeholder. If a database migration occurred, inspect data consistency with the application owner before declaring success.
If the change worsens the result, revert that specific change using the recorded state. A code rollback may require a compatible database rollback plan; do not restore a database blindly. Escalate with a timeline, redacted matching error, last known working version and actions already tested. Keep the distinction between an application fault and an unverified platform fault clear.
Common questions
Does a 500 mean DirectAdmin is broken? No. A website can return 500 while the panel and server remain available.
Should I enable public error display? No. Use access-controlled logs because traces can reveal paths and secrets.
Why does a static page work? It narrows the fault to a dynamic path or its configuration, but further log evidence is needed.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.