Services / Care / Always-on monitoring

We find out before your customers do

The worst way to learn your checkout is broken is a customer email, because most customers do not send one, they simply leave. Automated checks walk your critical journeys around the clock, so problems arrive as an alert with a diagnosis attached rather than as a complaint.

Start the conversation →See the technology

Why it matters

The cost is the wait

Silent failure is the expensive kind. A payment provider changes something and one card type stops working. A background job that syncs stock quietly stops running. A form starts failing for anyone on a particular browser. In every case the homepage looks perfect, nothing is obviously down, and the loss accumulates for days or weeks until somebody happens to notice, usually while doing something else entirely.

"Is the site up" is not monitoring. A server can respond cheerfully while the thing customers came to do is completely broken. Real monitoring walks the journeys that matter (logging in, searching, adding to basket, paying, submitting the enquiry) from outside your network, on a schedule, and tells you the moment one of them fails. Alongside that it captures the errors real users hit, the pages that got slower for a subset of visitors, and a searchable record of what the system was doing at the time.

The part that gets skipped is what happens after the alert. A dashboard nobody opens is not monitoring either. Each alert has to reach a named human inside the hours your plan agrees, with a runbook telling them what to check first, and it has to be tuned so it still means something, because a team that has learned to ignore alerts is in a worse position than a team with none.

What you actually get

Built to be trusted

The gap between a monitoring tool being installed and monitoring actually working is entirely in this list.

Checks that walk the journey

Automated browsers log in, search, add to basket and complete a test purchase on a schedule, from several regions. A checkout that fails while the homepage looks fine is precisely the outage a simple availability check misses.

Errors grouped and ranked by people affected

When something goes wrong for a user we capture what happened, in which release, on what device, and what led up to it. A hundred reports of the same fault arrive as one alert with a count, so work is prioritised by how many people are hurting rather than who complained loudest.

The slow tail, not the average

Average page speed hides the customers having a bad time. We track the slowest slice of real visits, server response, and the database queries behind them, because the slow tail is what people actually complain about, and averages are how it stays invisible.

A searchable flight recorder

Logs and traces retained for as long as your rules require, searchable and correlated. When something breaks we reconstruct exactly what happened rather than asking a customer to try it again while we watch.

Alerts that still mean something

Thresholds tuned deliberately, related alerts grouped, and anything that fires repeatedly without needing action either fixed or removed. Alert fatigue is the main way monitoring dies, so we treat a noisy alert as a defect in its own right.

Capacity and spend watched too

Traffic, storage, queue depth and cloud spend tracked against available headroom, so the conversation about scaling or budget happens in advance rather than during your busiest week or after an unexpected invoice.

Where it earns its keep

Same pattern, different desks

Different businesses, same shape of problem: something important fails quietly, and the cost is measured in the time it takes anyone to notice.

01 · Retail & e-commerce

The checkout that only fails for some people

The problem: Sales dip and nobody can say why. The site loads, test orders go through on the office machine, and the analytics show traffic arriving as usual. Somewhere between one payment method, one browser and one shipping region, a proportion of customers is hitting a wall and silently going elsewhere.
What we build: Synthetic checkout runs against a real payment sandbox across several browsers and regions, error tracking that groups failures by browser, device and payment provider, and alerts on conversion falling outside its normal band for the time of day rather than on a fixed number.
What changes: The failing combination is identified from the alert itself rather than from guesswork, and the same monitoring becomes the early-warning system for the next provider change nobody told you about.

02 · Logistics & operations

The integration that stopped three weeks ago

The problem: An overnight job pushes orders into the warehouse system. It failed quietly, nobody noticed because there is no screen showing that it ran, and the discrepancy only surfaced at month end, by which point reconciling it is days of manual work and some genuinely annoyed customers.
What we build: Heartbeat monitoring on every scheduled job, so silence itself raises an alert; queue depth and error-rate dashboards for each integration; and an explicit failure path for every automation: retry, then alert a named owner, then park the record for review rather than dropping it.
What changes: A job that stops running is a notification within the hour instead of a month-end discovery, and nothing disappears silently between two systems.

03 · SaaS & subscription products

Proving uptime, not asserting it

The problem: Enterprise customers want availability commitments in their contracts and evidence at renewal. Right now uptime is a feeling. When there is an incident, support and engineering find out at different times, customers hear about it last, and there is no record afterwards of what actually happened.
What we build: External availability measurement independent of your own infrastructure, per-release error tracking so a regression is caught within minutes of a deploy, a public status page tied to the same checks, and incident timelines recorded automatically for the post-incident write-up.
What changes: Availability becomes a reported figure with evidence behind it, and customers learn about incidents from your status page rather than from their own users.

The technology

The tools behind it, named

There is an open-source option and a commercial one for nearly every layer here. We pick based on what you need to keep in-house, what you are willing to pay monthly, and who has to read the result.

6 layers · 23 technologies

Is it up, and does it work?

Checks running from outside your infrastructure, from several regions, walking real journeys rather than pinging a homepage.

Uptime Kuma
Better Stack
Cloudflare
Checkly

Every error, traced to its cause

Application-level capture of what actually went wrong for a real user: the release, the device, the sequence of events leading up to it.

Sentry
OpenTelemetry
Datadog
New Relic

Numbers over time

Metrics collected continuously and drawn on dashboards, so a gradual degradation is visible as a trend long before it becomes an outage.

Grafana
Prometheus
Elastic
Grafana Loki

What real visitors experience

Speed and behaviour measured on actual devices in actual places, rather than on a fast laptop connected to office fibre.

Lighthouse
PostHog
Plausible
Google Analytics

Getting hold of the right person

Routing an alert to whoever is actually on duty, escalating if they do not acknowledge it, and staying quiet for things that can wait until morning.

PagerDuty
Opsgenie
Slack
Twilio

Telling customers what is going on

A page they can check without emailing you, driven by the same checks, so it cannot claim everything is fine while the site is down.

Statuspage
Instatus
Resend

Product names and logos are the property of their respective owners and are shown to describe the technologies we work with. Their use does not imply any partnership, sponsorship or endorsement.

How we deliver it

Live behind a human first

Basic coverage is running within days. Getting it genuinely useful (the right checks, the right thresholds, no noise) takes a few weeks of tuning against real traffic.

We work out what working means

Not a technical exercise. We sit down and list the handful of journeys that, if they stopped, would cost you money or reputation today, and the ones that could quietly fail for a week without anyone noticing. Those are the two lists monitoring has to cover.

We instrument the application

Error tracking wired in and tagged by release, traces on the slow paths, and structured logs that can actually be searched. Deploys are marked, so when errors jump we can see immediately whether a release caused it.

We write the checks

Synthetic journeys scripted against the real thing, running from multiple regions at a sensible frequency, plus heartbeats on every scheduled job and integration so silence raises an alarm rather than passing unnoticed.

We set thresholds with you

What wakes a person at 3am, what waits until the morning, and what is simply logged. This is a commercial decision as much as a technical one, and it is worth ten minutes of your time to get right.

We write the runbooks

Each alert points at a short document: what it means, what to check first, how to confirm it is really broken, and how to restore service. It is what makes a 2am response competent instead of exploratory.

We tune it every month

Alerts that fired without needing action get fixed or removed. Anything that broke without alerting gets a new check. Monitoring that is not maintained becomes wallpaper within a quarter, so this step is not optional.

Before you commit

The questions worth asking

Can you guarantee 100% uptime?

No. Nobody can, and a supplier who says otherwise is either mispricing the risk or hoping you will not read the exclusions. Your cloud provider has outages, so does DNS, so does the payment gateway, and so does the internet between you and your customers. What we commit to is how fast a problem is detected, how fast someone responds within your agreed hours, and how quickly service is restored, plus a rehearsed plan for the failures that are genuinely outside our control.

Does this mean someone is awake at three in the morning?

Only if you are paying for it. Around-the-clock human response costs considerably more than business-hours cover, and plenty of businesses genuinely do not need it: if nobody transacts overnight, an alert waiting until 7am is a rational trade. We will tell you honestly which category you are in rather than selling the larger plan by default. Automated monitoring itself runs continuously either way.

Are we going to be flooded with alerts?

You should receive almost none. Alerts route to us, and you hear about the ones that need a decision or that affected customers. Internally we start deliberately conservative and tighten as we learn what normal looks like for your system. A noisy alert is treated as a bug to be fixed, because the fastest way to break monitoring is to teach people to ignore it.

We are on shared hosting or a closed platform. Can you still monitor it?

Yes, though with less depth. External journey checks, client-side error capture, real-user speed measurement and status reporting all work regardless of where the site runs. What you lose is server-level metrics and detailed traces, which need access the platform may not offer. We will be clear about what we can and cannot see before you sign anything.

What does the tooling itself cost?

It varies widely, and it is worth modelling before committing. Self-hosted open-source options cost mainly the server they run on; commercial platforms bill on data volume and can grow surprisingly fast on a busy site. We size it against your real traffic during setup and will happily build you a capable stack out of open-source components if the monthly figure matters more than the polish.

Will monitoring slow the site down?

Slightly, and it is measurable rather than mysterious. Error tracking and tracing add a small amount of work per request, which is why traces are sampled rather than captured for every visit. Set up properly the overhead is a fraction of what one unnoticed slow query is already costing you, and we measure it so the claim is not merely reassuring.

How would you know if it broke tonight?

If the answer is that a customer would tell you, that is the gap. Tell us what your system does and we will map the checks worth having, and what it takes to run them.

Start the conversation →

Explore more

The rest of Ongoing Care & Support

Security & updates A real response promise Continuous improvement Software we didn't build ← All of Care