Monitoring is the ongoing check that a platform is healthy and available. It is part of keeping the service running after deployment, not just responding when something breaks. A useful monitoring culture helps the team spot trouble before a client has to report it. section 13.0 section 13.3
Look at the service from two directions:
- Outside in: check whether the solution works from a client’s perspective. This can reveal availability problems before clients alert you. section 13.6
- Inside out: track CPU, memory, and disk usage. Learn what normal usage looks like, then investigate unexplained changes before they affect clients. section 13.3.2
Internal signals can also guide capacity decisions: rising demand may call for more services, while unused resources may be removable. Bring application and infrastructure logs into a central location where possible so the team can compare events across systems, monitor them, and alert on problems. Include authentication activity alongside operating-system, network, and application logs. section 13.3.2
Trace a symptom across systems
Increased SQL errors in a web application may point to trouble on a database server, such as a long-running statement locking tables. Checking only the web application could miss the cause; comparing logs across subsystems gives the team a better lead. section 13.3.2
Monitoring also matters when the concern is security: real-time observation can reduce the risk of an attack going unnoticed. During production due diligence, ask, “How do you know all is well right now?” Follow up with which daily checks are made, which logs are reviewed, and which early warning signs people recognize. section 12.8 section 14.5.1
A practical self-check:
- Are solutions monitored from the client’s perspective? section 13.7
- Are internal metrics watched, and can the team investigate unusual changes? section 13.7 section 13.3.2
- Can the team connect an application error to events elsewhere in the platform? section 13.3.2
