What to send when you ask for help
What to include when you ask for Compute help, and what to leave out, such as keys, signed links and customer data.
Record the problem before retrying
A useful report says what you tried, what you expected, and what you actually observed. Start with the existing work reference and observation time. Do not repeat a submission, payment, or configuration change just to produce a better screenshot.
What a report shares, and what it never shares
A useful report is a closed set of safe fields: the operation or page, your client version, the observation time with time zone, a safe error code, and one job, batch, quote, artifact, or invoice reference relevant to the problem. For partial results, add expected and observed counts. For delivery, add the safe destination reference and current delivery state. For a payment question, identify the invoice and whether a transfer was already attempted.
It never includes an API key, a cookie, an authorization header, a password, a signed transfer URL, a connection string, a bank account detail, a private message, or a full customer payload. Do not paste an entire request, response, trace, or environment file — it may carry temporary access or private content. Describe a file's category, format, and size instead of attaching it, and select the fields above by hand.
Not every response includes a request ID or timestamp. Do not invent a missing field; your own observation time is useful when clearly labeled as such. Keep detailed evidence in your authorized environment, and share more only through a separately agreed protected process when it is necessary.
Review it before you send it
Contact's review step shows you the exact message before you send it. Nothing is sent until you confirm that review, and what you confirm is exactly what reaches us — never a summary, and never a version filled in afterward.
Use the actual contact route
Open Contact Lithi, choose Send us a message, and submit the concise description. The form accepts a message, not a customer-file upload. Its success message confirms submission, not resolution of the reported problem.
For a suspected vulnerability or exposure, use security reporting instead. Do not reproduce hostile inputs against provider machines.
Success is a safely submitted report with the unresolved outcome clearly stated. If submission itself is uncertain, preserve that fact and use the contact page's email fallback rather than sending repeated copies automatically.