Dashboards that watch the system's health continuously, and alerts that notify humans the moment something crosses a danger line.
Why it exists
Nobody watches dashboards at 3am, yet an outage at 3am still needs someone, and finding out from angry users is too late. Monitoring and alerts exist to watch the system continuously and notify the right person automatically when something crosses a threshold, so problems are caught as they happen, not hours later.
How it actually works
Monitoring tracks vital signs, error rates, response times, traffic, server load, on live dashboards. Alerts are rules on top: "if errors exceed 1% for five minutes, page the on-call engineer." Together they mean problems are caught by machines, often before users complain.
This is how teams find out about incidents fast rather than from angry tweets. The quality of monitoring largely determines how quickly things get fixed.
A senior PM walks you through it
A junior PM, stuck
On-call got paged during Friday lunch for checkout errors, and in standup I was asked what actually triggered the page. I said "the errors got bad" and that was clearly not enough. I want to point at the specific rule that fired and the exact moment it crossed, not wave at a dashboard.
A page is not a vibe, it is a rule crossing a line: a specific metric, over a specific threshold, held for a specific duration. TiffinBox's rule is "error rate above 1% for five minutes pages on-call". Here is the monitoring feed for that window. Watch the error-rate number climb and find the exact line where the rule is finally satisfied.
Monitoring feed, /api/orders error rate, Friday 13:03 to 13:11
2026-03-06T13:03:00ZINFOmonitor /api/orders error_rate=0.3% window=1m ok
2026-03-06T13:03:30ZINFOmonitor /api/orders error_rate=0.3% window=1m ok
2026-03-06T13:04:09ZINFOdeploy v2.4.1 rolled out to 100%
2026-03-06T13:04:30ZINFOmonitor /api/orders error_rate=0.5% window=1m ok
2026-03-06T13:10:01Z CRIT monitor rule "error_rate>1% for 5m" satisfied
2026-03-06T13:10:02Z CRIT monitor PAGE sent to on-call Nadia
2026-03-06T13:10:04ZINFOmonitor incident #4412 opened for /api/orders
Click a step to see the lines it points at.
Mistakes I've seen
Describing a page as "the errors got bad". A page is a named rule crossing a line; "error rate above 1% for five minutes, fired at 13:10" is checkable, "got bad" is not.
Confusing the first bad reading with the page. The rate crossed 1% at 13:05 but on-call was not paged until 13:10; the five-minute hold is the whole point, and missing it makes you think the alert was slow when it was doing its job.
Treating a page as an action. The page notifies Nadia and opens an incident; it does not roll back the deploy. Reading it as "the system handled it" leaves the incident running while everyone assumes it is fixed.
Tuning thresholds by feel. Set the rule too tight and it pages on every one-minute blip until people mute it; too loose and a real climb waits past five minutes. The number and the duration are a decision to make on purpose, with the cost of each error in mind.
Say in standup: "The page fired at 13:10 when the /api/orders error rate stayed above the 1% threshold for a full five minutes, from 13:05. The cause was the 13:04 deploy; the trigger was the sustained rate crossing the rule. It paged Nadia, who then made the rollback call." You named the exact rule that fired instead of pointing at a dashboard.
Where a PM meets this
"How will we know if this breaks?" is a fair launch question; a feature with no monitoring can fail silently.
Alert thresholds are tunable: too sensitive and people ignore them, too loose and problems slip through, a real balance.
Hear it in a meeting
"Error rate crossed the threshold, on-call just got paged."