> ## Documentation Index > Fetch the complete documentation index at: https://docs.basaltic.sh/llms.txt > Use this file to discover all available pages before exploring further. # Support > How to reach us, and what to include so we can help quickly. ## Contact **[ping@basaltic.sh](mailto:ping@basaltic.sh)** — account questions, billing, and anything not working the way these docs say it should. **[security@basaltic.sh](mailto:security@basaltic.sh)** — vulnerability reports and anything with a security impact. Please use this rather than general support. ## Before you write Check [basalticstatus.com](https://basalticstatus.com) first. If a region or a service is degraded, it will be there, and you do not need to wait on a reply to find that out. ## What to include The fastest tickets to resolve are the ones that let us find the request in our logs without guessing. * **What you called** — the method and full URL, e.g. `POST https://compute.sa-saopaulo-1.basaltic.sh/v1/instances`. * **When** — a UTC timestamp, or the `X-Date` you sent. * **The response** — the status code and the body. Our error bodies carry a machine-readable code; include it verbatim. * **The resource id or CRN**, if the problem is with something that already exists. * **Your account handle**, but never your `secret_access_key`. We never need it and cannot use it. If you are working with the CLI, `-v` prints the requests and responses to stderr and its output is exactly what we want to see: ```bash theme={null} basaltic compute instances list -v ``` ## Reporting a vulnerability Send it to **[security@basaltic.sh](mailto:security@basaltic.sh)**. Include what you found, how to reproduce it, and what you believe the impact is. Please give us a chance to fix it before disclosing it publicly. Do not test against other tenants' resources, and do not run denial-of-service or high-volume automated scans against the platform — those are indistinguishable from an attack from where we sit, and they page someone.