CLI and observability
Observe production behavior
Choose a small set of traffic, error, latency, and resource signals that reveal user impact without turning every dashboard tile into an alert.
8 minute lesson
Observability helps explain how the deployed system behaves over time. It is useful only when the signals lead to a decision or investigation.
Watch request volume, error rate, high-percentile latency, function duration, and the external dependencies most likely to fail. Web Analytics and performance products may add useful client evidence, but check current plan availability and privacy implications. Define alerts around sustained user impact, then link each alert to a short investigation and recovery procedure.
Measure from the user’s path outward. An increase in 5xx responses may come from application code, a database, or an upstream API; deployment IDs and request IDs connect the symptom to evidence. High-percentile latency shows the slow experience hidden by an acceptable average.
Every alert needs an owner, a time window, and a first action. Alert on a sustained error ratio or latency breach rather than a single failure, and include the production deployment and affected route in the notification. After a release, compare the new version with its predecessor, then either continue observing or execute the recorded rollback instead of debugging indefinitely under user impact.
Create a one-page operations note with four signals, their expected range, one alert condition, and the first log or dependency to inspect.
Lesson completed