Send the details that help
Include the server identifier, region, the time and timezone of the issue, expected behaviour and what you observed. A short reproduction is more useful than a large unfiltered log. Redact passwords, tokens and unrelated personal information.
Account access is sensitive
Support requests need a secure way to verify account control. Staff should never request your password, private SSH key, wallet seed phrase or full recovery-code set. Use only contact channels published on a verified domain.
Know the service boundary
Infrastructure support covers the machine and agreed network service. Application debugging, migrations and ongoing administration require an explicit managed-service scope. Confirm what is included before relying on support for a production workload.
Incident or security report?
A widespread service issue belongs in the incident process. A vulnerability needs a private verified security channel and careful disclosure. An individual application error needs its own reproduction and diagnostic context.
Send a report another operator can act on
Include the affected service identifier, region, time with timezone, observed error, recent change and a short reproduction. Distinguish an account problem, payment reconciliation, network reachability and an application failure. Remove passwords, tokens, seeds and customer data from attachments before submitting them.
What a good incident update should contain
An incident update should explain the affected scope, known impact, current mitigation and next update point. If the cause or recovery time is unknown, say so. Response and restoration targets come from the support agreement. Keep updates consistent with verified operational facts.
A little more clarity.
Should I send a wallet seed or root password to diagnose an order?
No. Use order and transaction identifiers for payment questions, and a scoped diagnostic or approved secure process for server support. Never send a wallet recovery phrase or private key.