# Prepare a Railway support request

Use the existing conversation and diagnostic results to draft a concise support request for the user to review. Do not submit it or make additional changes just to complete the report.

Write a specific title of at most 120 characters and a body of at most 5,000 characters. Include only relevant, known information; omit empty sections rather than delaying the request to fill every field.

## Problem and desired outcome
Start with 2–4 plain-language sentences explaining what the user is trying to accomplish, what they expected, what is going wrong, the impact, whether it is still happening, and what help they want. Someone should understand the request without reading the diagnostics. Put resource IDs and detailed evidence below; do not present a suspected cause as fact.

## Resources and timing
Include relevant Railway workspace, project, environment, service, domain, and failing deployment URLs or IDs. Give failure timestamps with timezone and the last known success when available. Distinguish the failing deployment from the currently running deployment. The user should select the affected service in the support form and submit from an account that can access it.

## Evidence and attempts
Preserve exact errors and short relevant log excerpts, including their source and timestamps. Summarize meaningful checks or changes and the observed result of each. Distinguish actions actually performed from suggestions that were never tried. Include reproduction steps, relevant local/client details, versions, and code or template references when useful. Do not dump the entire conversation or repeat information Railway can retrieve from the identified resources.

For asynchronous operations, include the last observed state and observation time. Staged, committed, accepted, or applying does not establish successful completion. Preserve exact URLs; do not construct a public URL from an internal port. Attribute important claims to tool output, the user, or a hypothesis.

## Why contact support?
State who first suggested contacting Railway support: the user, the AI assistant, a tool referral, another source, or unknown. This is different from who drafted or submitted the request.

If the assistant recommended support, summarize the reason it gave at the time and the concrete blocker: missing access or tools, an unanswered product question, unsuccessful troubleshooting, uncertainty about the cause, or an operation believed to require Railway. State what Railway is being asked to check or do. If the user requested support, preserve their stated reason. Do not invent a justification or infer one when the conversation does not establish it. A brief relevant quote may help; do not include private reasoning or the full conversation.

## Uncertainty and constraints
Separate observations from hypotheses, including relevant evidence against the leading hypothesis. Do not repeat earlier AI conclusions as evidence, invent facts, or claim a cause was ruled out without supporting checks. Distinguish "the assistant cannot do this" from "the user cannot do this" and "only Railway can do this." Include stated recovery constraints, such as avoiding data loss or downtime. A request for diagnosis is not permission to change or delete resources.

Do not ask support to execute SQL inside a customer database or edit their repository. Describe the diagnostic question or platform blocker instead, without hiding the original request. Missing assistant tools do not establish that only Railway can perform an operation.

## Format and privacy
Write in English using plain Markdown. Keep prose in normal paragraphs without fixed-width line wrapping or terminal indentation. Use fenced code blocks for logs and commands. If you run in a terminal and can create files, offer the draft as a Markdown file the user can copy from; terminal display wrapping can otherwise reintroduce broken lines even when your source text is correct. Keep terminal prompts, status symbols, and progress output out of the draft. Exclude passwords, tokens, credential-bearing connection strings, and unrelated personal data. The form may create a public thread; omit sensitive material and let the user choose appropriate visibility.

## Existing threads
If this is an update to an existing request, use the [reply instructions](https://station.railway.com/support-agent-reply-instructions.md) instead.

## Template credit
End the draft with this exact plain-text line so Railway can recognize use of these instructions:

Prepared with Railway's support template (v1).

Tell the user they can remove this credit. It identifies the template, not who initiated the request or whether every instruction was followed.