Contact
All systems System

Monitoring and alerting

Each server and application reports its status on a schedule and is health-checked, and an alert goes to a named owner when one goes quiet or fails a check. Dashboards and reports show the state of every system.

Describe what you need

What you get

  • A heartbeat and health checks for every system in scope, watched in a cloud monitoring service or a self-hosted monitoring stack
  • Alert routing that sends each alert to the named owner of the system
  • Dashboards that bring metrics, logs and traces together and show the state of each system
  • Scheduled checks on patching and on certificate and licence renewal dates
  • Health checks after each release, with automatic rollback when a check fails
  • A monthly overview of what happened, what changed and what needs attention next, when we run the system

How it works

  1. 01

    Agree what is watched

    We list the systems in scope and name an owner for each system's alerts.

  2. 02

    Add heartbeats and health checks

    Each system sends a heartbeat on a schedule and gets health checks, watched in a cloud monitoring service, for example Azure Monitor, or in a self-hosted stack.

  3. 03

    Route alerts to the owner

    When a system goes quiet or fails a health check, an alert goes to its owner. When we run the system, the alert comes to us and we start troubleshooting.

  4. 04

    Build the dashboards

    Metrics, logs and traces are collected in one place. Dashboards show the state of each system, with trends and anomalies.

  5. 05

    Check and report on a schedule

    Patching and certificate renewal are checked on a fixed schedule, and each release is health-checked after deployment. When we run the system, a monthly overview lists what happened and what changed.

Problems it solves

  • ProblemA system stops without an error message, so nothing triggers an alert.

    SolutionEach system reports its status on a schedule. When one goes quiet or fails a health check, an alert goes out.

  • ProblemAlerts go to a shared mailbox nobody reads, so users report outages before IT notices.

    SolutionEach alert goes to the named owner of the system. When we run the system, alerts come to us and we start troubleshooting.

  • ProblemStatus is spread across separate consoles, so there is no single view of which systems are healthy.

    SolutionMetrics, logs and traces are collected in one place, and dashboards, for example in Grafana, show every system in one view.

  • ProblemA certificate or licence expires unnoticed, and a service stops working.

    SolutionCertificate and licence renewal dates are tracked ahead of expiry and checked on a fixed schedule, together with patching.

  • ProblemA failed release stays live until someone notices it.

    SolutionEach release goes out through a pipeline, for example in GitHub Actions, and is health-checked after deployment. If a check fails, it rolls back automatically.

What it covers

  • For exampleAzure Monitor, Application Insights
  • Alert routing to a named owner
  • For examplePrometheus, Loki, Tempo, Log Analytics
  • For exampleGrafana
  • Patching checked on a schedule
  • Certificate and licence renewal tracking
  • For exampleGitHub Actions
  • Windows and Linux servers
Typical scope

Sized to the environment and the number of systems in scope. It usually follows an environment setup or a review, and an existing environment can be added after a short handover check. We then run it on a monthly plan, or hand it over to your team with documentation and runbooks.

Next step

Send a short description of what you need and the systems involved. We reply with proposed next steps.

Describe what you need