18 October 2026 · 10 min read
Most teams do not lack monitoring. They have an uptime check here, a dashboard there and a log search nobody trusts. What they lack is a design: which signals matter, what good looks like, and who gets woken up when it is not. A holistic observability suite is that design. It is a set of components that each answer a different question and that are joined together so one problem can be followed from a customer's browser to the line of code that caused it.
The diagram below shows the whole picture. Each box links to its section in this guide. If you would rather talk it through for your own systems, see SRE Consulting Services.
Select any part of the suite to see what it does, what it connects to and what we deliver.
OBSERVABILITY
From signals to reliability
Observability framework design
What we do
A written plan for what you will measure, where the data comes from and who acts on it. We start from your services, your users and your incident history rather than from a tool, so the framework fits the way your team works.
How it connects
Decides which signals each part collects, who owns them and in what order they are rolled out. Everything else is built from it. Linked to: Real User Monitoring (RUM), Synthetic monitoring, Application performance monitoring (APM), Centralised log management, SLIs, SLOs and error budgets, AIOps and alert noise reduction.
Typical deliverables
Tools we use
COLLECT
Gathered once with OpenTelemetry, sent to the backend you already use: Datadog, Grafana or CloudWatch.
Traces
Services, via OpenTelemetry
Metrics
Infrastructure, services and APIs
Logs
Application, audit and security
Real user data
Browsers and devices (RUM)
Synthetic checks
Journeys and API checks
DECIDE
Turn signals into targets and noise-free alerts.
SLOs
AIOps
ACT
Get the right information to the right people.
Alerts and on-call
The right engineer, with a runbook
Incident management
One incident, one timeline
Engineering teams
Clear ownership and next steps
Dashboards and reporting
A reliability view for leadership
Read the diagram from the top down. Four components collect signals: Real User Monitoring shows what visitors actually experience, synthetic monitoring checks the journeys you care about around the clock, application performance monitoring shows where time and errors come from inside your services, and centralised logs hold the detail that explains a failure. They are connected by shared identifiers, for example a trace ID that appears in the front-end session, the trace and the log lines, so you can jump from one to the next.
Those signals feed service level objectives, which say what good looks like in numbers and how much unreliability you can afford. Burn-rate alerts then page people only when the objective is genuinely at risk, and AIOps techniques group and enrich those alerts so one incident produces one page with a runbook attached. Under all of it sits the observability framework, the written plan for signals, ownership, tooling and rollout order. Without it, the components drift into five separate tools that nobody can reason about together.
A written plan for what you will measure, where the data comes from and who acts on it. We start from your services, your users and your incident history rather than from a tool, so the framework fits the way your team works.
Typical deliverables
Questions we ask in discovery
Tools we have hands-on experience with here: Datadog, Grafana, OpenTelemetry, CloudWatch.
We turn "the site should be fast and reliable" into numbers you can track. For each critical user journey we pick service level indicators (SLIs) that reflect what users feel, set service level objectives (SLOs) the business agrees to, and define how the error budget is spent.
Typical deliverables
Questions we ask in discovery
Tools we have hands-on experience with here: Datadog, Grafana, CloudWatch.
Real User Monitoring measures what actual visitors experience in their own browsers and devices, including Core Web Vitals (LCP, INP and CLS), page load, front-end errors and slow third-party scripts. We design what to collect, how to sample it and how to keep it consistent with UK GDPR and PECR.
Typical deliverables
Questions we ask in discovery
Tools we have hands-on experience with here: Datadog, CloudWatch, OpenTelemetry.
Scripted checks that run on a schedule and catch problems before customers do: is the site up, can a user log in, does checkout complete, is the API returning the right answer. We build browser journeys with Playwright and API checks, and wire them to alerts that mean something.
Typical deliverables
Questions we ask in discovery
Tools we have hands-on experience with here: Playwright, Datadog, CloudWatch.
Distributed tracing and service-level metrics that show where time and errors come from inside your application. We instrument services with OpenTelemetry where it makes sense, so you are not locked to one vendor, and send the data to the backend you choose.
Typical deliverables
Questions we ask in discovery
Tools we have hands-on experience with here: OpenTelemetry, Datadog, Grafana, CloudWatch.
AIOps means using correlation, anomaly detection and automation to cut alert noise and speed up diagnosis. It only works on clean, well-labelled signals, so we get the foundations right first, then add the pieces that earn their keep.
Typical deliverables
Questions we ask in discovery
Tools we have hands-on experience with here: Datadog, Grafana, CloudWatch.
One searchable place for application, infrastructure and audit logs, with structure, retention and cost under control. Logs are linked to traces by ID so you can jump from a failing request to the exact lines that explain it.
Typical deliverables
Questions we ask in discovery
Tools we have hands-on experience with here: Datadog, Grafana, CloudWatch, OpenTelemetry.
Observability consulting helps a team decide what to measure in its systems, collect that data in a consistent way and turn it into alerts and dashboards people can act on. It covers metrics, logs, traces, real user data and synthetic checks, plus the service level objectives that tell you whether users are getting a good experience.
Monitoring checks for problems you already know about, such as a server being down. Observability is the ability to ask new questions of your system from the data it emits, so you can work out why something is slow or broken even when you did not predict the failure. Good practice needs both.
A service level indicator (SLI) is a measurement of user experience, such as the proportion of requests that succeed. A service level objective (SLO) is the target for that measurement over a period, for example 99.9 percent over 30 days. The error budget is the allowed shortfall: 99.9 percent over 30 days leaves about 43 minutes of full unavailability to spend on changes and incidents.
Often not. We work with the tools you already have and recommend a change only when it solves a clear problem. We have hands-on experience with Datadog, Grafana, OpenTelemetry, CloudWatch and Playwright, and we use OpenTelemetry where practical to keep your data portable.
Real User Monitoring records what real visitors experience, so it shows the full variety of devices, networks and behaviour but only after someone has been affected. Synthetic monitoring runs scripted checks on a schedule, so it finds problems when nobody is using the site, such as overnight, but only for the journeys you have scripted. Most teams need both.
AIOps applies correlation, anomaly detection and automation to operational data. In practice the most valuable uses are grouping related alerts into one incident, detecting unusual behaviour that fixed thresholds miss, and automating the first diagnostic steps. It depends on clean, consistently labelled data, which is why the framework comes first.
No. SREmonitor is a ready-made service for uptime, performance and privacy-policy checks on websites, and it needs no setup. Consulting is for teams who need a bespoke observability design across their own applications and infrastructure. The two are separate, and you can use either on its own.
Use the short enquiry form on the SRE Consulting Services page. Tell us what you run and what is hurting, and we will reply by email to arrange a short discovery conversation. There is no obligation.
More from the blog
Want this designed and built for your systems?
Answer a few short questions and book a consultation with an expert.
Request a consultation →