The problem
Services launched first and got monitoring later, if someone remembered. The first sign of trouble with a new service was usually a user telling us.
How I measured it
Compare what's deployed with what's monitored:
# apps running on the platform
cf apps | awk 'NR>4 {print $1}' | sort > deployed.txt
# apps reporting to APM (New Relic REST API v2)
curl -s -H "X-Api-Key: $NR_API_KEY" "https://api.newrelic.com/v2/applications.json" \
| jq -r '.applications[].name' | sort > monitored.txt
# deployed but not monitored
comm -23 deployed.txt monitored.txt
The list was long, and most of it was services launched in the last few months.
Why it kept happening
Monitoring wasn't in anyone's definition of done. Teams launched when the feature worked. Monitoring was something a different team did, on a different schedule.
The process change
A monitoring onboarding checklist that had to be complete before a service took production traffic:
- APM agent installed and reporting.
- A synthetic check on the main user journey.
- Health and performance dashboard in the shared view.
- At least one alert on a user-facing symptom, with an owner.
We made it easy to say yes: templates for the agent config, the synthetic
script and the dashboard, so the checklist took an afternoon, not a sprint.
The comm check above ran weekly and anything new on the list got a ticket.
What I learnt
A checklist only works if doing the items is easy. Templates made the rule cheap to follow, and the weekly diff caught what slipped through anyway.
What I do now
- Put monitoring in the definition of done for launch.
- Provide templates so the checklist takes hours, not days.
- Diff deployed against monitored on a schedule.
stage 0 runs this diff on your estate → get the free audit