Browse this section

Reporting a slow application or server

Describe the user-visible symptom before assuming that more CPU or RAM is the solution. Slow requests may originate in the application, database, storage, external API or network. Useful measurements make the next investigation much more focused.

Collect a short evidence set

  • Affected URL or operation, approximate response time, expected behaviour and when the problem began.
  • Whether all users or only certain networks are affected, plus relevant times with timezone.
  • Recent deployments or configuration changes and representative CPU, RAM, disk-latency and network graphs.
  • Redacted application errors or request identifiers that help correlate logs with the incident.

Avoid restarting every component before collecting evidence unless immediate recovery requires it. Do not run uncontrolled benchmarks or load tests on production. Include the service reference and business impact so support can prioritise the investigation within the agreed support arrangements.

Was this guide helpful?

Related guides

Preparing a server migration

A migration is a coordinated application and data change. Moving files alone may miss databases, scheduled tasks, certificates, runtime versions or external integrations. Prepare a tested d…

DNS changes during a migration

DNS changes are not seen everywhere at exactly the same moment. Authoritative records, resolver caches and application caches can affect what a user reaches. Plan a period in which the old …

Choosing useful monitoring and alerts

Monitoring is useful when an alert identifies an action someone can take. A running server does not necessarily mean that logins, payments or other important application functions work. Agr…

Need help applying this to your service?

Tell us your service reference and what you need to achieve. Never include passwords or private keys in a ticket.

Contact support →
← All knowledgebase topics