Useful failure reports
Support Diagnostics
Vibecodr errors should help creators, agents, and support identify the failing surface without exposing private data.
Public-safe support diagnostics guide for Vibecodr failures.
Implementation focus
Use this when a Studio action, Pulse call, CLI workflow, MCP tool, player, or embed fails and you need to report enough detail for support to trace it safely.
Expected outcomes
- Read stable error fields and retryability.
- Choose the right recovery path from status codes.
- Include useful request details in support reports.
- Avoid sharing secrets, tokens, or private bundles when reporting failures.
Read the stable error fields
Vibecodr errors should give creators, agents, and support stable, public-safe facts. The most useful fields are the human-readable error, machine-readable code or `errorKey`, whether the operation is `retryable`, and request id or trace id values when present.
These fields help creators, agents, and support talk about the same failure without exposing secrets, raw private bundles, stack traces, provider tokens, or internal storage state.
- `error` is the user-facing summary.
- `code` and `errorKey` are better for programmatic handling and support reports.
- `retryable` tells callers whether immediate retry is likely to help.
- A request id or trace id helps support find the event without needing private payloads.
Status codes point to the next action
Treat status codes as recovery hints. A 400 usually means the request shape needs to change. A 401 or 403 means access or authorization failed. A 404 can mean the project, post, or Pulse endpoint was not found. A 409 usually means state changed underneath the request. A 413 means the payload belongs in another upload path. A 429 means slow down. A 5xx means the platform or upstream dependency failed after the request reached the backend.
When reporting an issue, include the surface or URL you opened, status, `errorKey`, request id, expected behavior, actual behavior, and whether the same thing happens signed in and signed out.
- Do not include secrets, raw tokens, or credential-bearing URLs in reports.
- Do include the smallest reproduction path.
- Do include whether the failure happened in Studio, player, embed, vanity, Pulse, CLI, or MCP.
Example and read next
Example: an import or Pulse call returns 413 with an errorKey and request id. Treat it as a payload-shape issue, move large bytes into the upload path, and include the request id if support needs to trace it.
Use these related pages when you need the next layer of guidance. They point to the most likely follow-up tasks, not every page that happens to touch the same system.
- Read next: Troubleshooting
- Read next: Calling Pulses
- Read next: MCP & CLI
- Read next: /support/bug-report