Observability prompts are useful when the team can see that something failed but cannot explain where or for whom. Adding more logs is not always the answer. A service may already produce plenty of events while missing the one identifier that joins a request to its background work. These prompts start from a user outcome and ask which metrics, logs and investigation steps would make that outcome understandable.
Choose one service outcome to observe
Describe an important operation, its dependencies and what the user considers success. Include existing dashboards, a sanitized log sample and the incidents the team struggled to diagnose. State the traffic pattern and operational ownership. This prevents a generic monitoring checklist from becoming a large instrumentation project with no clear consumer.
Google's monitoring guidance discusses user-visible symptoms and useful service signals. Use it as a foundation for selecting evidence. The prompts below are original exercises for choosing that evidence in a specific product; they do not assume every team needs Google's operating model.
Map a user failure to a diagnostic path
Ask the agent to follow a request through the actual components and name what each signal would establish. A useful plan distinguishes an unavailable service from a successful response that contains an incorrect result. Include background processing if the user-visible outcome happens after the initial response. Otherwise the dashboard may report success before the real work fails.
Design an observability plan for {{user_operation}}.
Use {{service_map}} and {{existing_telemetry}}.
List user-visible failure modes and the signal that detects each one.
For every proposed metric, log or trace, state its diagnostic purpose,
owner, bounded fields and expected volume. Identify gaps that telemetry
alone cannot verify. Prioritize the smallest useful instrumentation set.
Make logs useful without collecting everything
Provide a real diagnostic question, such as why an upload never reached processing. Ask which events answer it and which fields connect them. Avoid unconstrained values in aggregations and sensitive bodies in logs. A clear event name and a safe correlation identifier often help more than serializing the entire request object.
Review logs for {{diagnostic_question}} in {{code_paths}}.
Trace the request and asynchronous work using {{sample_logs}}.
Propose event names, severity and minimal fields needed to join the path.
Remove credentials and unnecessary personal data from examples.
Show one successful and one failed timeline, plus what remains unknown
if an event is missing. Estimate volume from our stated request rate.
Turn an alert into an action
A page should tell the responder what changed, how much impact exists and where to begin. Ask the agent to review an actual alert history rather than inventing universal thresholds. Include the service's normal variations and any maintenance periods. The output should explain how the alert resolves as well as how it fires.
Review {{alert_rule}} using {{alert_history}} and {{service_objective}}.
Explain the user impact, false positives and missed failures supported by
the evidence. Propose a threshold or window change with its tradeoff.
Draft the notification and first investigation steps. If no immediate
human action exists, suggest an appropriate non-paging review path.
Do not claim reduced noise without checking a comparable period.
Validate signals with a controlled failure
Choose a test environment and deliberately trigger one known failure mode. Confirm the expected event, metric or trace appears and leads to a useful next step. Check recovery visibility too: a service that silently recovers can leave responders working an obsolete incident. Record sampling and retention limits beside the result.
Save the approved observability prompt in Kipt with variables for operation, evidence and owner. For implementation through a shared instrumentation standard, continue with the OpenTelemetry prompts.