Monitoring and security patching
Knowing that something is wrong before your customers tell you, and keeping the software patched against the vulnerabilities that are disclosed every week whether or not anyone is watching.
Finding out from a customer
The checkout has been failing for a segment of users since a deploy on Tuesday. Nothing alerted, because the health check only confirms the server responds — not that the thing customers came to do still works. By the time a complaint arrives and is escalated, it is Thursday.
You’ll recognise this if
- Outages reach you through customers or social media
- You have no idea how quickly your site loads for real users
- Nobody is tracking security advisories for what you run
- Alerts fire so often that everyone has muted the channel
What we actually deliver
Monitoring of what users actually do
Checks that exercise the real journeys — signing in, searching, checking out — rather than confirming a server is reachable. Most damaging failures leave the server perfectly healthy.
Error tracking with real context
Errors captured, grouped, and prioritised by how many people they affect, with enough context to diagnose without asking a customer to reproduce it.
Continuous patching against advisories
Dependencies watched for disclosed vulnerabilities, assessed for whether they actually affect you, and patched — urgently when it matters, on the normal cycle when it doesn't.
Alerts tuned to be believed
Thresholds set so that an alert means something. We would rather send five alerts a month that get read than fifty that get filtered.
The way we approach it
Instrument the transaction that matters
Every system has one path that must not fail — the order, the booking, the submission. That gets monitored first and most carefully.
Assess before patching
Not every published vulnerability affects you; some are in code paths you never call. We assess actual exposure rather than reacting to every advisory with equal urgency.
Write the runbook before the incident
Who is called, what is checked first, how to roll back. Decided calmly in advance rather than invented at two in the morning.
What changes
- Problems detected before customers report them
- Real numbers for uptime and page performance
- Known vulnerabilities patched on a defined cycle
- An alert channel people still pay attention to
Asked often enough to answer here
Do you offer 24/7 cover?
Monitoring runs continuously on supported builds. Round-the-clock human response is a separate arrangement — we would rather agree explicit hours we will genuinely meet than imply cover we cannot staff.
Is this a penetration test?
No, and they serve different purposes. This is ongoing operational security — dependency patching, configuration, monitoring. A penetration test is a point-in-time assessment by a specialist firm, and we will tell you when one is warranted.
Can you monitor a system you didn't build?
Yes. Adding proper monitoring to existing software is a well-defined piece of work and usually one of the highest-value things you can do to an unmonitored system.
Related
Wherever you’re starting from, let’s figure out the next step.
Tell us what you’re building — we’ll tell you honestly whether we’re the right team for it.