SEC-01
Least-privilege access
Each integration gets the narrowest scope that lets the work function. Nothing more.
Stage 04 · RunMonitoring & alerting
Knowing before the customer does
Most systems are monitored in the sense that a dashboard exists. Far fewer will wake somebody when the thing that matters to a customer stops working.
- Access stays in your accounts
- Every change on record
- Written, auditable deliverables
- C01Define what "working" meansIn scope
- C02Alert on symptoms, not causesIn scope
- C03Give every alert an owner and a runbookIn scope
- C04Make logs and traces correlatableIn scope
- C05Tune ruthlesslyIn scope
- C06RehearseIn scope
In short
Useful monitoring alerts on symptoms a customer would notice — checkout failing, orders not reaching the warehouse, response times degrading — rather than on individual resources. The test is whether every alert that fires requires action. Once a monitor produces alerts people routinely ignore, it has stopped being monitoring and become noise, and the real outages hide inside it.
- 5
- Warning signals
- that say this is the work
- 6
- Controlled steps
- each ships something you keep
- 4
- Written refusals
- lines we do not cross
Self-audit
Signals this is the work
Tick the ones that are true where you are. Nothing is sent anywhere — the answer is for you, not for us.
If more than one of these is true today, the problem is usually further along than it looks from the outside. That is not a sales line; it is what the cost of waiting does.
Readiness checklistMonitoring & alerting
0 of 5 true
Nothing ticked yet.
How we do it
The sequence
Each step ships something you keep. You can stop after any of them and still be better off than when you started.
Start with step one- 01
Step 1 of 6
Define what "working" means
In business terms: an order can be placed, a payment clears, data reaches the ERP. That is what gets monitored.
- 02
Step 2 of 6
Alert on symptoms, not causes
High CPU may be fine. Checkout failing is never fine. Alert on the second and use the first to explain it.
- 03
Step 3 of 6
Give every alert an owner and a runbook
An alert with no named owner and no first step is a notification, not an alert.
- 04
Step 4 of 6
Make logs and traces correlatable
Enough context to follow one request across services, so diagnosis is reading rather than guessing.
- 05
Step 5 of 6
Tune ruthlessly
Every alert that fires without needing action gets fixed or deleted. Noise is the thing that kills monitoring.
- 06
Step 6 of 6
Rehearse
Test that the alert path actually reaches a human, including at 3am on a weekend. Most on-call gaps are discovered during a real incident.
Assurance
Secured and auditable by default
These controls apply to every engagement, including this one. They are engineering decisions, not a certificate on a wall — and you can check each of them.
SEC-02
Credentials in your name
Accounts and keys live in your tenancy. You can revoke any of them without asking us.
SEC-03
Every change logged
Changes, deployments and incidents leave a written trail you can audit.
SEC-04
Restores tested, not assumed
A backup only counts once it has been restored. We test, and we report the result.
SEC-05
Separate environments
Development never touches production credentials or unmasked customer data.
SEC-06
A documented exit
Runbooks written as we go. Leaving means revoking our access — nothing is held back.
What we will not do
The refusals
The things we turn down are a better description of how we work than the things we sell.
Standing commitmentsMonitoring & alerting
- 01
We will not: Add dashboards nobody looks at and call it observability.
- 02
We will not: Alert on every metric available because the tool makes it easy.
- 03
We will not: Report uptime from a check that only proves the homepage loads.
- 04
We will not: Set up on-call without agreeing who is actually on it.
Questions
Before you ask
Anything else, ask on the first call. There is no charge for working out whether this is the right fit.
Talk about a problemWhat should we monitor first?
The transaction that makes you money, end to end, as a customer experiences it. If orders can be placed and reach fulfilment, most other problems are degradations rather than outages. Start there and expand, rather than instrumenting everything and drowning.
How many alerts is too many?
If anyone has ever ignored one because it is "probably nothing", you are already past the limit. A healthy setup produces few alerts and every one means something. Getting there means deleting monitors, which teams find harder than adding them.
Which tools do you use?
Whatever fits the stack and the budget — Grafana, Prometheus, Datadog, New Relic, or the cloud provider's own. Tool choice matters far less than whether the alerts are meaningful and somebody is genuinely on the other end.
What about on-call?
It only works if it is explicit: who is on, how they are reached, what they are expected to do, and what happens when they cannot. Informal on-call — where everyone assumes the same person will notice — fails exactly when it is needed.
Tell us what isn’t working.
One process, one system, one decision you are stuck on. An engineer replies within one working day with how we would approach it, and whether it needs building at all.