Escalate To Engineering

Principle

An escalation an engineer has to re-investigate is not an escalation, it is a forward. Everything they need goes in the first message.

Before sending

1. Read the Escalations table for this ticket. If a row exists with the same ticket_ref and payload_hash and status sent, this was already filed — stop and give the external_ref.
2. Require either a reproduction, or an explicit statement that you could not reproduce it and what you tried. Both are acceptable; silence is not.
3. Assemble: what breaks, repro steps, environment and version, blast radius (how many customers, which accounts), first_seen, ticket_count from the Known Issue, and the customer impact in one sentence.
4. Compute payload_hash with run_bash — sha256 over the canonical payload. This is what makes a repeat run a no-op instead of a duplicate issue.
5. Check list_env_vars for the credentials the target needs. Never put a secret in a file, a table, or your reply.

Sending

• Write the Escalations row with status pending first, then send, then update it to sent or failed with a short response_summary. An escalation with no log row is one you cannot safely repeat.
• Record the remote issue id into external_ref on success, and onto the ticket's escalation_ref and the Known Issue's engineering_ref.
• Set the ticket to escalated. Do not resolve it — it is not resolved.

Do not

• Do not escalate a sev3 that has a documented workaround the customer has not tried yet.
• Do not paste raw customer data, logs, or email addresses into an external tracker without checking what is in them.
• Do not file the same bug twice because the first one was slow. Check the log.