Tell us what needs attention.

Name the affected application or service and describe what people cannot do. Distinguish a complete outage from a problem affecting one user, one integration or a particular transaction. Include the start time and time zone, and say whether the issue is continuing or intermittent.

Priority should reflect the impact rather than the complexity of the error message. If a workaround exists, explain what it allows and what remains blocked. An existing service agreement determines the actual escalation process and response commitments. An email request does not replace your agreed incident escalation process, so use your established channel for an active incident.

Record the steps that led to the issue, the expected result and the actual result. Include a release or ticket reference if it helps connect the report to a recent change. A sanitised error message can help an engineer locate the relevant event without requiring an entire log export.

Remove passwords, tokens and personal records. Do not repeatedly retry a transaction if it may create duplicate payments, orders or other irreversible actions. Note what has already been attempted and whether it changed the behaviour. Preserve relevant evidence through your approved incident process rather than making unrelated production changes while preparing the report.

Provide a contact who can answer questions about the workflow and confirm whether a proposed fix restores it. Include availability and any access constraints. If another provider owns part of the service, record that dependency and any existing reference so the investigation can be coordinated.

After a change, verify the original business task as well as the technical health checks. An error disappearing from a dashboard does not prove that a delayed record has been reconciled. Keep follow-up work visible, including any remaining data repair or monitoring changes. Download and review this PDF before sharing it through the agreed support route.