Monitoring & SRE

Knowing a service is degraded before your users tell you, and having a path to fix it.

Discuss your project Learn this field

What is it?

Service level objectives, alerting that correlates with real user impact, and the incident practice around them. The aim is fewer, better alerts: a page should mean something is actually wrong and there should be a runbook for it.

For a technical reader

Service level objectives should be expressed from the user's perspective, because component uptime and service usability are different things — every instance can be healthy while the service returns errors. Error budgets turn reliability into a quantity that can be traded against release velocity, which is what makes the conversation concrete rather than aspirational. The operational discipline that matters most is alert hygiene: every alert should require human action and map to a runbook, because an alert that does not is training people to ignore the ones that do.

Our services

SLO definitionObjectives based on user-facing behaviour, with error budgets and an agreed policy for spending them.
Alert remediationRemoving alerts that require no action and attaching runbooks to the ones that remain.
Observability implementationMetrics, structured logs and distributed tracing across services.
Incident practiceOn-call rota, incident command roles and blameless postmortems with tracked actions.

What’s covered

SLIs and SLOs
Objectives expressed as what users experience, with error budgets
Alerting
Alerts that require action, each mapped to a runbook
Distributed tracing
Request paths across services, so latency can be attributed rather than guessed
On-call
Rota, escalation policy and handover practice
Incident command
Defined roles during an incident, and blameless postmortems with tracked actions

Business problems we solve

Users report outages before monitoring doesMonitoring watches components rather than user journeys. SLOs fix the perspective.
On-call is burning people outAlmost always alert noise. Removing non-actionable alerts is the first intervention.
Incidents take too long to diagnoseWithout tracing, attribution across services is guesswork. Instrumentation shortens diagnosis.
The same incident keeps happeningPostmortem actions that are never completed. Tracking them to closure is the difference.

Our delivery approach

  1. 01
    Define SLOs from the user's viewObjectives based on what users experience, not component uptime. A server can be up while the service is unusable.
  2. 02
    Cut the alert noiseAlerts that do not require action are removed. Alert fatigue is why real incidents get missed.
  3. 03
    Write the runbook with the alertNo alert ships without a documented response. Working it out at 3am is not a strategy.
  4. 04
    Review incidents blamelesslyPost-incident reviews focused on systemic causes, with actions tracked to completion.

Solutions & project types

Examples of the work we take on in this area. These describe project shapes, not named client engagements.

SLO programmeDefining objectives and error budgets for critical services and reporting against them.
Alert rationalisationAuditing an existing alert set and removing what does not require action.
Observability rolloutConsistent tracing and metrics across an existing estate, introduced incrementally.
Incident response setupOn-call, escalation and postmortem practice for a team taking on production ownership.

Technologies & platforms

Metrics

  • Prometheus
  • Datadog
  • CloudWatch
  • OCI Monitoring

Logs

  • Loki
  • Elasticsearch
  • Splunk
  • OpenSearch

Tracing

  • OpenTelemetry
  • Jaeger
  • Datadog APM
  • Tempo

Alerting & on-call

  • PagerDuty
  • Opsgenie
  • Alertmanager

Dashboards

  • Grafana
  • Datadog
  • Kibana
Learn this field

Where to start with monitoring & sre.

Secondary to the work itself, but genuinely useful if you are building the skill. Every link goes to official documentation or an official channel.

Beginner

  • The difference between monitoring and observability
  • Metrics, logs and traces, and what each is for
  • Read a dashboard and say what is wrong
  • Why uptime percentage alone is a weak measure

Intermediate

  • Defining SLIs and SLOs from user journeys
  • Error budgets and burn-rate alerting
  • Instrumenting a service with OpenTelemetry
  • Writing a runbook tied to an alert

Advanced

  • Incident command and coordination at scale
  • Blameless postmortem facilitation
  • Capacity and load modelling
  • Chaos experiments and failure injection

Certifications

  • Prometheus Certified Associate (PCA)
  • Google Cloud Professional Cloud DevOps Engineer
  • Datadog Fundamentals certifications

Practice projects

  • Define an SLI and SLO for one real user journey
  • Audit your alerts and delete every one that needs no action
  • Instrument two services with tracing and follow a request across them
  • Write a burn-rate alert on an error budget
  • Run a postmortem on a real incident and track the actions to closure
FAQs

Questions we get asked.

What SLO should we target?

Whatever the business actually needs, which is rarely as high as people first say. Each additional nine costs disproportionately, so the target should be a deliberate trade-off.

Do we need to adopt all of SRE?

No. SLOs, alert hygiene and blameless postmortems deliver most of the value and can be adopted without restructuring anything.

Can you provide on-call cover?

Yes, as part of a managed service. It works best combined with application support so whoever is paged can actually fix the problem.

How do we stop alert fatigue returning?

A standing rule that every alert must be actionable and have a runbook, plus a periodic audit. Without the audit it creeps back.

Managed Services

Related services.

Application supportOngoing support for the applications we build and the ones you already run.Cloud & infrastructure operationsRunning the platform day to day: patching, capacity, resilience and cost.Continuous improvementA funded, prioritised backlog after go-live, so the system keeps getting better.Specialized talentSenior engineers, Oracle specialists and data people embedded in your team.
Start the conversation

Talk to our experts about monitoring & sre.

Tell us where you are. A specialist will read it and reply within one business day.

Discuss your project