# Prepare a Railway support reply

Draft a concise reply for the user to review and post in their existing thread. Use the support conversation and actual diagnostic results. Do not submit the reply or run additional commands or make changes merely to fill this template. Keep the body under 5,000 characters and omit irrelevant sections.

## Answer the latest questions
Read the latest support response first. Answer each outstanding question directly, preserving its order when useful. If the thread is private or unavailable to you, ask the user to share the relevant response with secrets removed; do not claim to have read it. Say which answers are unknown or which checks were not performed and why.

## Report what changed
Briefly state whether the original problem persists, improved, changed, or is resolved. For each suggestion actually tried, report the action, when it happened (with timezone), and the observed result, including exact errors and short relevant logs. Distinguish attempted actions from planned actions. Staged, committed, accepted, or applying does not mean an operation succeeded. Include changed resource or deployment IDs and distinguish them from the original failing deployment.

Correct earlier inaccurate statements explicitly. Attribute facts to tool output or the user's report and label hypotheses. Do not treat a previous AI diagnosis or support suggestion as verified merely because it was suggested. Do not repeat the original ticket or paste the entire conversation.

## Explain the remaining blocker
State what is still unresolved and the specific clarification or help needed from support. If a suggested step cannot be performed, explain the actual access, tooling, safety, or permission limitation. Distinguish an assistant limitation from a user limitation or a Railway-only operation. Do not ask support to run SQL in the customer's database or modify their repository. Preserve constraints such as avoiding downtime or data loss; a diagnostic reply does not authorize resource changes.

Only report recovery as confirmed when the user or observed checks establish it; say how it was verified and what remains untested. If the user confirms resolution, a short confirmation is enough. Keep the same issue in the existing thread. Do not manufacture a new escalation reason or repeat who initiated support unless correcting that information.

## Format and privacy
Write in English with normal Markdown paragraphs, no terminal-width line wrapping, prompts, or progress output. Fence code and logs. Keep exact URLs unchanged. Exclude tokens, passwords, credential-bearing connection strings, and unrelated personal information. Respect the existing thread's visibility. If working in a terminal, offer a Markdown file to copy from so terminal wrapping does not alter the draft.