Browse this section

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. Agree monitoring coverage and ownership as part of the service scope.

Select checks around the workload

  • Infrastructure: capacity, storage health, network reachability and resource trends.
  • Application: the public endpoint and a safe representative health check that does not create real transactions.
  • Recovery: backup success, age of the latest usable copy and certificate renewal status where included.
  • Operations: alert recipients, escalation path, coverage hours and suppression during approved maintenance.

Record what each alert means and the first investigation steps. Thresholds should reflect the application and its normal patterns. A monitoring check is not an availability guarantee, and monitoring outside the agreed scope should be requested explicitly.

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 …

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 me…

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