Skip to main content

Get help

This guide explains how to get support, run self-service diagnostics, and submit effective technical reports.

How support works​

Support requests route directly through your team administrators and project leadership:

  1. Your project admin. Open the web console at https://console.codyhill.dev, select Project → IAM & members, and identify members holding the admin role. Project admins manage project quotas, secrets, permissions, and resource settings directly.
  2. Your organization admin. Organization admins hold administrative authority across all projects in your organization.
  3. Your technical lead or account contact. For infrastructure queries beyond project settings, contact your designated technical team lead or Crusoe account representative.

Self-service checks​

Before submitting a report, complete these three quick diagnostic checks:

  1. Search error messages in the troubleshooting guide. Section headings match exact API error strings. Refer to dedicated troubleshooting guides for agents, serverless services, and functions.
  2. Review platform considerations for operational guidelines and default configurations.
  3. Check the FAQ for general platform usage questions and the glossary for clear term definitions.

What to include in a report​

To help support resolve your issue quickly, include these five items in your report:

1. The request_id​

Every API response returns errors in a standard JSON format containing a unique request ID:

{"error": "a plain-English description of what went wrong", "request_id": "8f3c1a2b"}

The request ID is also returned in the X-Request-Id response header and displayed in web console notifications. Including the request ID allows support engineers to locate exact log lines for your request.

If using curl, capture the response headers:

curl -sS -D - -o /tmp/body.json \
  "$CAI_API/v1/agents/research-buddy" \
  -H "Authorization: Bearer $CAI_TOKEN" | grep -i x-request-id

Output:

X-Request-Id: 8f3c1a2b

2. Exact command or request​

Include the exact CLI command or HTTP method and path executed (redact sensitive secret keys):

platformctl deploy ./my-agent --name my-agent

3. Project and resource details​

Specify your project name (or project short ID) and the target resource name (agent, function, service, topic, or database index).

4. Workload logs​

Include recent log output from your application. Retrieve historical logs using the CLI:

platformctl logs my-agent --history

This returns the recent log entries, formatted as <timestamp> <stream> <message>.

5. Expected outcome​

Provide a clear, one-sentence description of the expected behavior versus what actually occurred.

Self-service resources​

QuestionWhere to look
"Who modified a project setting?"Check the project audit log in the web console or run platformctl audit list. See break-glass and audit.
"Why was a deployment rejected?"Check current quota usage under Quotas in the console. See quotas and audit.
"Why do I see a 404 error?"A 404 Not Found response indicates missing resources or insufficient project access grants. See troubleshooting.
"What are the default resource limits?"Review the complete limits table in the limits reference.

Data privacy and security​

Platform administrators manage project permissions and resource settings. Project application data remains private to your project team. Platform engineers access project data only when explicitly requested during active support troubleshooting using audited, temporary break-glass grants. For details, see break-glass and audit.