Skip to content

Monitoring That Means Something

Know before your customers do.

Anyone can install a monitoring tool. The question is what it buys you. We build monitoring that pays for itself: fewer 3am calls, evidence for every change, capacity you can plan, and checks the vendor said were impossible.

Runs on
CheckMK · Nagios · Prometheus · PRTG
Watched from
as many locations as you like
When it can't
we write the check
api-gateway · p95 latency · last 30 min
live
800 600 400 200 -30m -15m now alert · 650ms warn at 540ms · cache warmed · 2m11s
api-gateway p95 212ms
tls: shop.example 41d left
queue: orders 1.2k backlog
disk: db-01 /var 63%
probe: eu-west up
probe: us-east up

What it looks like when it works

An incident, from first symptom to nobody noticing

Pick a scenario. The line is the thing going wrong. The red dashed line is where your customers would start to notice. Watch how much happens before it gets there: detection on trend rather than a fixed number, an alert with the right context, and an automated runbook that fixes it while the graph is still climbing.

% used on /var t+0m
t+0t+20mt+40m customers notice here alert threshold
time to detect
time to resolve
customer impact
none
event log

    detect on trend

    A threshold tells you the disk is at 80%. A trend tells you it will be full in eleven minutes. Only one of those is worth waking up for, and only one of those lets a script fix it in time.

    alert with context

    The page carries the graph, the last three changes to that system and the runbook link. The person on call starts fixing, not investigating.

    runbook, not a human

    The alert hands off to the same Ansible and Terraform that built the estate. Rotate logs, scale a pool, renew a certificate, restart a consumer. Humans review the ticket in the morning. That's the automation service.

    Why bother

    What monitoring actually buys you

    Nobody wants a monitoring platform. They want to stop being surprised. These are the things we measure ourselves against.

    Fewer 3am calls

    An alert should be a decision, not a noise. We tune on trend and rate of change, group related failures into one page, and route it to whoever can actually fix it. If it can't be acted on at 3am, it waits until 9.

    Evidence for every change

    Every deploy, patch and config change is annotated on the graphs. When someone asks "did that release make things slower?" you answer with a picture, not a feeling.

    Capacity you can plan

    Disk, memory, connections and queue depth are forecast from their own history. You buy hardware or scale out on a schedule, not in a panic.

    Proof for customers and auditors

    Uptime, latency and error budgets are measured from outside your estate, from more than one place, and kept. When a contract asks for 99.9%, you show it.

    Blackouts wired into automation

    Patch nights and planned changes put their own hosts into downtime before they start and lift it after the checks pass. Maintenance never pages anyone.

    One place to look

    Cloud consoles, on-prem boxes, SaaS APIs, certificates, backups and batch jobs on one board with one alerting policy. The question "is it us?" gets a yes or no in seconds.

    Monitoring as a Service

    Monitored from where it matters

    A check from inside your own network tells you the server is up. It doesn't tell you that customers in one region can't reach it, that a certificate chain is broken for one browser, or that DNS is returning the wrong answer from one resolver.

    You pick your preferred tool, give us the list of things to watch and tell us how many locations you want them watched from. We handle the rest: probes, alerting, notifications, and the continuous tuning that keeps the platform honest as your estate changes.

    When one location fails and three don't, the alert says "regional" and goes to the right team. That distinction is the difference between a quiet night and a war room.

    • you choose
      the tool
    • you list
      what to watch
    • you decide
      how many locations
    • we run
      everything else
    shop.example api.example eu-west ok · 41ms us-east ok · 41ms ap-south timeout · 3/3 eu-north ok · 41ms verdict: regional — 3 of 4 locations healthy · page network owner, not the app team
    check_orders_api.py · custom check
    $ ./check_orders_api.py --base https://api.example --cert --queue orders walking /v2/orders … 3 pages, 412 items in 0.83s p50 118ms p95 212ms p99 340ms [OK ] under 650ms budget tls: api.example chain valid, 41 days left [OK ] renew at 14d queue: orders backlog 1,204 rate 38/s [WARN] drain ETA 32s, threshold 1,000 last successful batch: 04:00:12 (today) [OK ] 1 orders_api p95=212;650;900|backlog=1204;1000;5000|cert_days=41;14;7 WARN orders backlog high # one line the platform understands; graphs, thresholds and history come for free

    Why we're different

    When the product says no

    Every monitoring product has a wall. A vendor API it can't read, a log format it doesn't parse, a business metric it has no idea exists. Most people stop at the wall and live with the blind spot.

    We don't. If it has an API, a log file, a port or a database, we can write a check for it in Python that plugs into the platform you already have. The platform does what it's good at: scheduling, graphing, thresholds, alerting, history. Our check does the one thing the product couldn't.

    "Not supported" describes the product. It doesn't describe your monitoring.

    • Business checks: orders per minute, failed logins, batch completion
    • Anything with an API: SaaS, cloud services, network gear, appliances
    • Predictive checks: time-to-full, time-to-expiry, rate of change
    • Cross-checks: does the backup exist and does it actually restore

    Questions we get

    Monitoring as a Service, answered

    Why Monitoring as a Service instead of hiring? +

    Simply put, it's cheaper. Start-ups and small operations put everything into the product, and rightly so. Hiring someone experienced, then giving them the months it takes to build a monitoring platform properly, pulls that focus away. You tell us which tool you prefer, what you want watched and from how many locations. We build it, run it, tune it, and keep improving it.

    Can I log in and manage it myself? +

    Of course. We can configure the platform fully or partially, but you're the boss. Our job is to make it easy for you to spot bottlenecks, measure performance, and see the impact when something goes wrong. Full admin access, your data, your rules.

    Can you integrate with this and that? +

    Probably. Part of the first conversation is asking what you actually want to achieve with the platform, then working out which integrations get you there: ticketing, chat, paging, CMDB, cloud APIs, or something we write specifically for you.

    Is it secure? +

    Security is a sliding scale with convenience on one side and the Secret Service on the other. How deeply our platform integrates with your estate is entirely your call: agentless checks from outside, read-only agents, or full integration with a hardened, audited path. We'll tell you what each option buys you and what it costs you.

    What actually happens at 3am? +

    Whatever we agreed. Some alerts trigger an automated runbook and you read about it in the morning. Some page a person with the graph, the recent changes and the suggested fix in the message. Some just open a ticket. Nothing pages a human unless a human can do something about it.

    Do I have to change tools? +

    No. If you already run CheckMK, Nagios, Prometheus or PRTG we'll make it earn its keep. If you have nothing yet we'll recommend based on what you run and who has to look at it. If the product can't do something you need, we'll extend it rather than tell you to live without.

    Next step

    Tell us what keeps surprising you.

    Bring the last incident that nobody saw coming. We'll tell you what would have caught it, and how long it would take to build.