Troubleshoot Slow or Unreliable Self-Hosted Apps

Slow pages, timeouts, and intermittent errors in self-hosted apps can come from the app, its database, the host, storage, or the network. Use the steps below to isolate the failing layer, collect useful evidence, and make one change at a time; you’ll need administrative access to the app’s host and, ideally, its logs and monitoring.

What You’ll Need

Access to the server or hosting platform, including a terminal if available.
The app’s logs and configuration, plus access to its database and reverse proxy if you manage them.
A way to reproduce the issue and note when it happens, such as a browser and a clock.
A recent backup before changing configuration, upgrading, or restarting services.

Step-by-Step

Describe and reproduce the symptom. Identify which page or action is slow, whether it affects every user or only one device or network, and whether it happens constantly or at particular times. Record the time, approximate duration, URL or action, and any displayed error. Test in a private browser window and, if possible, from a second device or network. This helps separate an app problem from browser, DNS, or local-network trouble.
Check whether the service is reachable. From a client, load the app and note whether it fails to connect, returns an HTTP error, or loads slowly. From the server, check that the relevant service is running with the tools for your operating system or container platform. For a container, inspect its status and recent logs rather than assuming that a running container means the application is healthy. Check the reverse proxy and DNS only if the problem occurs before the request reaches the app.
Inspect logs at the time of a failure. Review application, web-server or proxy, database, and system logs around the timestamp you recorded. Look for repeated exceptions, failed database connections, timeouts, permission errors, restarts, and out-of-memory messages. Match entries by time and request if possible. Avoid posting logs publicly without removing passwords, tokens, session identifiers, email addresses, and other private data.
Check host resource pressure. Inspect CPU use, memory, disk space, and disk I/O while reproducing the slow action. A process constantly using CPU may indicate a stuck job or heavy request; exhausted memory can trigger swapping or process termination; a full disk can prevent databases and apps from writing. Check the host’s monitoring tools or operating-system utilities. Compare readings during normal operation and during the issue instead of relying on a single snapshot.
Check storage and database health. Confirm that the data volume is mounted, writable, and has free space. Look at database logs for connection limits, slow queries, locks, or recovery errors. If only pages that search or save data are slow, the database is a likely layer to investigate. Use the database’s own diagnostic tools and documentation; do not delete database files, run repair commands, or change indexes without a backup and a clear reason.
Trace the request path. If direct access to the app works but the public URL does not, investigate the reverse proxy, TLS termination, DNS, firewall, and any external tunnel or load balancer you use. Check proxy logs for upstream connection errors and timeouts. If both direct and public access are slow, focus first on the application, database, host, and storage. Test from more than one network before changing DNS.
Look for recent changes and scheduled work. Compare the start of the problem with app or system updates, configuration edits, certificate renewals, backups, imports, and scheduled jobs. Temporarily pause a nonessential job only if you understand its effects. If a change clearly coincides with the outage, use your backup and documented rollback procedure rather than making several speculative edits.
Make one low-risk change, then verify. Examples include freeing space by removing known disposable files, correcting a documented setting, or restarting a service after saving its logs and confirming a safe restart is appropriate. Restarting may interrupt users and can hide evidence, so do not make it the first diagnostic step. After a change, repeat the same test and compare response time, logs, and resource use. If it did not help, revert it before testing another cause.
Escalate with a concise evidence bundle. If the cause remains unclear, collect the app and proxy versions, deployment method, timestamps, sanitized errors, relevant resource readings, and the exact reproduction steps. Include what changed and what you tested. Consult the app’s documentation or maintainers, and never share secret keys, database credentials, or a complete unredacted configuration file.

Common Mistakes

Restarting everything immediately: this can erase useful evidence and briefly mask a recurring fault.
Changing several settings at once: if performance improves or worsens, you will not know which change mattered.
Assuming a healthy-looking container proves the app is healthy: its process may be running while dependencies or requests are failing.
Deleting data, logs, or database files to free space without confirming what they contain or whether the app needs them.
Exposing an admin panel directly to the internet or sharing logs and configuration that contain secrets.

Tips

Keep a short incident note with timestamps, symptoms, changes, and results. It makes intermittent problems easier to compare.
Set up basic monitoring for disk space, memory, service availability, and database health before an incident.
Use health checks that test a real dependency when possible; a process-only check can report success while the database is unavailable.
Keep backups and periodically verify that you can restore them. A backup that has never been tested may not be usable.
Make updates during a planned window, back up first, and read release notes for required database migrations or configuration changes.

Troubleshooting

The app is unreachable, not just slow: Check the service status, listening address, firewall rules, proxy upstream, and DNS resolution. Test locally on the host before changing public DNS. If the service recently restarted, inspect its startup logs for missing files, invalid configuration, or unavailable dependencies.

It is slow only at busy times: Compare CPU, memory, database connections, and storage activity during busy and quiet periods. Check for backups, scheduled imports, or other jobs that overlap with the slowdown. Avoid increasing timeouts as a first fix: that can make requests wait longer without addressing the bottleneck.

It works directly but not through the proxy: Confirm the proxy points to the correct address and port, and check upstream logs, forwarded headers, and timeout settings against the app’s documentation. If only HTTPS fails, inspect certificate validity and the TLS configuration without disabling certificate checks.

Logs show no useful errors: Confirm that the app is writing to the log location you are viewing and that the timestamp and time zone match. Reproduce one specific action while watching the relevant logs. If the issue is sporadic, increase diagnostic logging only as documented and return it to normal afterward; verbose logs can consume disk space or expose sensitive data.

A restart helps, but only temporarily: Record resource use and logs before the next restart. Repeated recovery after a restart can point to a memory leak, growing queue, blocked worker, or connection exhaustion. Treat the restart as temporary recovery, not a diagnosis.

Frequently Asked Questions

Should I restart a slow self-hosted app?
A restart can restore service, but first capture logs and resource readings if users can safely wait. If you do restart, confirm it is safe for active users and check whether the underlying issue returns.

How can I tell whether the app or the server is the bottleneck?
Compare app response times with CPU, memory, storage, and database activity while repeating the same request. A resource spike or dependency error can narrow down the layer, though further logs may be needed to establish the cause.

What should I check when only one user has trouble?
Test another browser or device and another network. If other users can access the app normally, check that user’s browser extensions, cached site data, DNS, and local network before changing server settings.

Can I increase a timeout to fix intermittent errors?
Only if evidence shows a legitimate operation needs more time and the relevant app or proxy documentation supports the change. A higher timeout can conceal an overloaded or unhealthy dependency and tie up connections longer.

Is it safe to update the app while troubleshooting?
Do not combine an update with unrelated experiments. Back up first, check release notes and compatibility requirements, and use a maintenance window. If the problem began after an update, follow the documented rollback process.

What information should I share when asking for help?
Provide the deployment method, versions, exact symptoms, timestamps, sanitized log excerpts, and tests already performed. Remove credentials, tokens, private URLs, and personal data before sharing anything.

General steps for current mainstream versions; menus can differ by device and version. See the disclaimer or report an error.

More in this bed

The whole Tech How-To bed →