Logging and Observability Review
By Ollie · Published · Updated
Reviews what a service logs and measures, then sets the levels, fields and alerts that let on-call find a problem in minutes without drowning in noise.
Prompt template
## Logging and Observability Review Review the logging and monitoring of this service. - Service description: [textarea: What it does and its dependencies] - Sample log lines: [textarea: Paste ten to thirty real lines with secrets removed] - Current metrics and alerts: [textarea: What exists today] - Logging stack: [text: Datadog or Cloud Logging or ELK] - Typical incident: [textarea: A recent failure and how it was diagnosed] - Traffic level: [dropdown: Low, Medium, High, Very high] Judge the logs against the question an on-call engineer asks at 3 a.m.: what failed, for whom, and why. Check each sample line for level (errors only for things needing action, warnings for odd but handled events), a stable message, and structured fields such as request id, user or tenant id, operation, duration and error type. Flag logs that leak personal data, tokens or full payloads. Identify missing events: request start and end, calls to dependencies, retries, and state changes. Then propose the four golden signals as metrics (latency, traffic, errors, saturation) and for each a sample alert with a threshold and the action expected, favouring alerts on symptoms users feel over causes. Say which noisy logs to drop or sample at this traffic level. End with a prioritised list of changes and the dashboard panels to build first.