# What to Include in a Support Request The Roboflow Support team resolves issues faster when a request includes enough detail to reproduce the problem. Find your situation below and include the listed information when you reach out. ## What to Always Include Regardless of the problem type, these five things speed up every support case: 1. **Project and workspace**: the workspace ID or a direct link to the affected project or workspace. (Needed when you submit by email; otherwise we usually have it automatically.) 2. **Workspace access**: [grant the Roboflow Support team access to your workspace](/support/sharing-a-workspace-with-roboflow-support.md). 3. **Exact error**: the verbatim error message or response body, not a paraphrase. 4. **Time window**: specific UTC timestamps, not "yesterday." 5. **What you tried**: each attempt and its result. ## Inference API Errors Your production application starts receiving HTTP 4xx or 5xx responses from `serverless.roboflow.com`. Error messages may include "Internal error," "Model is temporarily not ready - retry request," "Could not acquire model manager lock," or timeouts after 30 seconds. Failure rates spike suddenly, often within a narrow window of time. These errors can stem from platform-side infrastructure incidents, model eviction from memory under load, or client-side request patterns that overwhelm capacity. Without a time window and a request log, it is difficult to zero in on the specific issue. What helps most: * Exact time window of the failures, including timezone or UTC offset. ("2026-05-22 12:30–12:40 UTC" is far easier to act on than "this morning".) * The full inference endpoint URL (ex: `https://serverless.roboflow.com/test-endpoint/11` for the [Serverless API](/deploy/serverless-hosted-api-v2.md), or `name.deployment@roboflow.com` for a [dedicated deployment](/deploy/dedicated-deployments.md)). * A screenshot or log export of the error responses, showing HTTP status codes, response bodies, and timestamps. A screenshot of your application or monitoring dashboard showing the event is ideal. * Approximate request volume during the window: total requests sent, how many failed, and the sending pattern (burst vs. steady). * Whether failures are still ongoing or have resolved. * Whether credits were consumed for failed requests. Example submission: > "We saw a \~90% failure rate hitting between 11:20 and 11:35 AM UTC on 2026-05-22. We were sending roughly 150 requests/hour at the time. The errors returned HTTP 503 with body {"message":"Internal error."}. Attached is a screenshot of our application log. The failure appears to have self-resolved around 11:40 AM. Our workspace id is fleet-pulse. Were we billed for the failed requests?" ## Inference Performance Problems The inference server runs correctly but consumes more memory than expected, grows over time, slows down under load, or produces unacceptably high latency for your use case. Common variants include memory growing unboundedly over hours on a Jetson device, a large model taking too long to load on first request, or throughput degrading under parallel batch requests. Memory and latency depend on model architecture, batch size, concurrency settings, image dimensions, hardware, and [inference server](/deploy/self-hosted-deployment.md) version. Almost every variable matters. What helps most: * Inference server version: the exact Docker image tag (ex: `roboflow/roboflow-inference-server-jetson-5.1.1:1.2.6`). * Hardware specs: GPU model, total RAM, and whether you are on Jetson and which JetPack version. * Model IDs and types of every model loaded (ex: `object-detection-5gavt/16`, YOLOv8-s, ViT 224×224), plus whether TRT packages exist for the device. * Client configuration: `max_concurrent_requests`, `max_batch_size`, and how batches are constructed on the client side. * A memory or CPU usage graph over time showing the degradation pattern (ex: a screenshot from `jtop`, `htop`, or a monitoring tool showing memory over roughly one hour). * Typical image size in KB, or exact pixel dimensions if known. * Environment variable overrides in use (ex: `USE_INFERENCE_MODELS=True/False`). * Steps already tried, including version rollbacks and flag changes, and the effect of each. Example submission: > "We're running roboflow/roboflow-inference-server-jetson-5.1.1:1.2.6 on an NVIDIA Jetson AGX Orin (JetPack 5.1.1). We load 7 models simultaneously: 2 YOLOv8-s object detection and 5 ViT classification models. After \~2 hours under production load (max\_concurrent\_requests=10, max\_batch\_size=100, image size \~50KB), memory climbs from 8GB to \~15GB. Attached is a jtop graph. We tried setting USE\_INFERENCE\_MODELS=False, which roughly halved memory but also reduced accuracy." ## Serverless Workflow Errors A Roboflow [Workflow](/workflows/what-is-workflows.md) (accessed via the Workflows UI or `serverless.roboflow.com/infer/workflows/...`) returns errors, times out, or produces unexpected results. Errors may be HTTP 500 "Internal error," 502 "Bad gateway," or silent failures where jobs appear to run but return no data. This is distinct from simple model inference failures: it typically involves multi-step pipelines, custom Python blocks, or complex block chains. Workflows can fail at any step in the pipeline. Knowing which block is at fault, how many requests were sent and in what pattern, and the exact workflow definition narrows down the root cause. What helps most: * The full workflow URL (ex: `https://serverless.roboflow.com/infer/workflows/test/test-workflow`). * A breakdown of when failures occurred, including timestamps and approximate request counts per time window. * HTTP status codes and full response bodies for the failing requests. "500 Internal Error" alone is far less useful than the full response body. * Whether failures are total (all requests fail) or partial (some succeed). * [Workspace access for the Roboflow Support team](/support/sharing-a-workspace-with-roboflow-support.md), so we can inspect the workflow definition and server-side logs. * Any recent changes to the workflow before the failures started (new blocks added, models swapped, image inputs changed). * For batch jobs: the [batch job](/deploy/batch-processing.md) ID from the "Activity" section, expected vs. actual output record count, and job duration. Example submission: > "Our workflow at returned 170 HTTP 500 responses out of 195 requests between 12:33 and 12:40 UTC on 2026-05-25. Requests came in bursts of \~15 at a time. The response body was {"message":"Internal error."} for all failures. The workflow recovered on its own after \~10 minutes. We haven't changed the workflow recently. I've granted workspace access to ." ## Model Training Issues A [training](/train/train.md) job fails outright, gets stuck, produces a generic error popup with no details, consumes credits without producing a trained model, or the model behaves unexpectedly after training (ex: max detections are lower than expected, or training on a large dataset hangs during version generation). Training failures can come from dataset characteristics (corrupt images, label format problems, class imbalances), resource constraints, or platform bugs. The support team needs to look at your specific project and dataset. What helps most: * The model type and size you attempted to train (ex: RF-DETR Nano, YOLOv8-L, SAM3). * The model name or a direct link to the affected model (ex: `app.roboflow.com/my-workspace/my-project/models/my-model`). * The dataset version number used for training. * The error message verbatim, copied and pasted in full rather than paraphrased. If it appears in a popup, screenshot it. * The training job ID if visible in the UI. * Whether credits were charged for the failed attempt. * Number of images and classes in the dataset version. * Any recent changes to the dataset before the failure (new images added, class names changed, preprocessing settings altered). * For foundation model fine-tuning (ex: SAM): the dataset size, prompt type used, and where in the process it crashed. Example submission: > "Training job for model YOLOv8-L on dataset version 3 of project foo-bar in workspace baz-co fails every time with a generic popup error, no further detail shown. The dataset has \~2,400 images across 12 classes. I've been charged credits for two failed attempts. Here is a screenshot of the error popup. Workspace access has been granted to support." ## Dataset & Image Visibility Issues Images that were uploaded do not appear in the dataset view (the header count differs from the number actually visible when browsing), images added to a dataset after labeling disappear, a dataset version preparation hangs indefinitely, or a batch ZIP upload appears to succeed but images are not accessible. These issues often require backend log inspection. The support team needs a precise project identifier and ideally a record of the specific upload event. What helps most: * The discrepancy in numbers: how many images the platform shows vs. how many are actually visible when you browse the dataset tab (ex: "Header says 1,004 images but only 368 show when browsing"). * When the upload occurred, which helps correlate with platform events. * The upload method used: drag-and-drop in the browser, Python SDK, REST API, ZIP upload, or mobile app. * For batch or ZIP uploads: the batch job ID from the "Activity" section if available. * A screenshot showing the discrepancy (header count vs. browse view). Example submission: > "My project foo\_bar\_2 in workspace abc\_def shows 1,004 images in the project header but only 368 are visible when I click into the dataset tab. I uploaded the images via drag-and-drop on 2026-05-25 around 9 AM EST. Workspace access has been granted. Screenshot attached." ## Roboflow App UI Errors Something in the Roboflow web app isn't working as expected outside of the annotation editor: pages fail to load or stay stuck on a spinner, actions like deleting a dataset version appear to complete but have no effect, settings panels don't open, uploads stall in the activity queue, the usage dashboard won't render, or buttons trigger no response. UI bugs are frequently caused by a failing or slow network request happening behind the scenes, or a JavaScript error, something the visible interface doesn't surface directly. The browser's developer tools expose what's going wrong at the network and JavaScript level. What helps most: * A screen recording (Loom, video, or GIF) demonstrating the bug. This is the single most valuable artifact for these cases. * A screenshot of the browser network request log, which shows whether any requests are failing or long-running. See [Chrome's network panel documentation](https://developer.chrome.com/docs/devtools/network) for how to open it; other browsers have similar tools. * Any errors in the browser console log. See [Chrome's console documentation](https://developer.chrome.com/docs/devtools/console/log) for how to access it; other browsers have similar tools. * Your browser name and version (ex: Chrome 124 on macOS 14.4). * Step-by-step reproduction steps: what you clicked, in what order, starting from a fresh page load. * Whether the bug appeared recently, and whether it coincides with a platform update you noticed. * The exact expected behavior vs. actual behavior. * Whether the issue is consistent or intermittent. Example submission: > "On the dataset tab of project `test-project` (workspace `test-workspace`), clicking 'Delete version' on version 3 shows a success toast but the version remains listed. The network log screenshot shows a `DELETE` request returning `500 Internal Server Error`. The console shows `Uncaught TypeError: Cannot read properties of undefined`. Browser: Firefox 126 on Ubuntu 22.04. Reproduced in both normal and private windows. Screen recording attached." ## Annotation Tool Bugs A tool in the Roboflow annotation editor behaves incorrectly: keyboard shortcuts stop working, selecting one tool reverts to another, undo (Ctrl+Z) deletes more than expected, Label Assist keeps loading indefinitely, or annotations are not saved when they should be. Annotation bugs are often browser-specific, OS-specific, or caused by recent platform deployments. A screen recording is almost always more informative than a written description. What helps most: * A screen recording (Loom, video, or GIF) demonstrating the bug. Annotation behavior is difficult to describe in words and easy to show, so this is the single most valuable artifact for these cases. * A screenshot of the browser network request log, which shows whether any requests are failing or long-running. See [Chrome's network panel documentation](https://developer.chrome.com/docs/devtools/network) for how to open it; other browsers have similar tools. * Any errors in the browser console log. See [Chrome's console documentation](https://developer.chrome.com/docs/devtools/console/log) for how to access it; other browsers have similar tools. * Your browser name and version (ex: Chrome 124 on macOS 14.4). * The project type (Object Detection, Instance Segmentation, Classification, etc.) and the specific annotation tool in use (polygon, polyline, bounding box, smart polygon). * The keyboard shortcut or action that triggers the bug, with step-by-step reproduction steps. * Whether the issue affects all images or specific ones. If specific, share the project link and image name or ID. * Whether the bug appeared recently, and whether it coincides with a platform update you noticed. * The exact behavior expected vs. what actually happens. * Whether the issue is consistent or intermittent. Example submission: > "In projects my-test-project and my-other-test-project (workspace test-workspace), the polyline tool has three bugs introduced recently: (1) zooming with Ctrl+scroll while the polyline tool is active switches to the bounding box tool; (2) Ctrl+Z now deletes the entire annotation instead of just the last point; (3) pressing Esc now saves the annotation instead of discarding it. Here are two Loom recordings showing each behavior: \[link 1], \[link 2]. Browser: Chrome 124 on Windows 11." ## API Authentication Errors API calls to model inference endpoints, the Roboflow Python SDK, or the HTTP API return 403 Forbidden with a message like "Missing or insufficient permissions." This may happen immediately after upgrading a plan, when trying to access a private model, or after an API key was rotated. 403 errors can be caused by an incorrect or expired API key, using a workspace-level key instead of a project-level key (or vice versa), accessing a model from a plan that doesn't include that feature, or a delay in permissions propagating after a plan upgrade. What helps most: * The full error response: the complete HTTP status code and response body, not just the status code. For SDK errors, the full Python traceback. * The endpoint or SDK method being called (ex: `detect.roboflow.com/model-name/version`, `InferenceHTTPClient`, `CLIENT.infer()`). * The model ID and version number. * The type of API key in use, workspace or project. Do not share the key itself, just specify the type. * Whether the key was recently rotated or the plan was recently changed. * A redacted code snippet showing how you construct the API call, with the actual key replaced by a placeholder like `YOUR_API_KEY`. * Whether this worked before, and what changed. Example submission: > "I'm getting HTTPError: 403 Client Error: Forbidden when calling . I'm using the workspace-level API key. This started after I upgraded from the Free Plan to Core yesterday. The model is private. Here is the full Python traceback: \[paste]. The workspace is my-test-workspace. Workspace access granted." ## Account Access Problems You're unable to log in to Roboflow: the login page keeps loading, a Google [SSO](/workspaces/single-sign-on-sso.md) login is blocked, a forgotten-password reset isn't working, or an account is locked because a connected Google account is unavailable. Access issues are often tied to the specific email or identity provider in use. They can also be caused by OAuth scope changes on Google's end or by browser or extension interference. What helps most: * The email address associated with the account you're trying to access. * The login method: email and password, Google SSO, or GitHub SSO. * The exact error message or behavior: "page keeps loading," "invalid credentials," "account not found," or a specific error code. * A screenshot of the error state. * Browser name and version, and whether you've tried an incognito/private window or a different browser. * Whether this is a new issue or has always been this way (ex: a newly created account vs. an existing one that stopped working). ## Workspace & Project Management Issues You can't [delete a workspace](/workspaces/delete-a-workspace.md) or project (the deletion button appears to do nothing or returns an error), a workspace accidentally upgraded to the wrong plan, ownership won't transfer, projects become inaccessible after a billing failure, an image upload limit is hit, or a [public project](/datasets/make-a-project-public.md) accidentally exposes private data. What helps most: * The specific action that's failing and the error message or behavior observed. * A screenshot of the error state or the undesired project state. * For deletion issues: confirmation that you've already deleted all projects and images within the workspace, a common prerequisite. * For accidental upgrades: the workspace IDs for both the one that was upgraded and the one that was intended, and the approximate time of the change. * For image limit issues: how many images are in the workspace currently and what the limit shown is. ## Credits & Usage Issues Credits deplete faster than expected, credits are charged for failed training jobs or failed inference, or the [usage dashboard](/billing/credits/view-credit-usage.md) isn't loading. What helps most: * The workspace name where the credit issue occurred. * The approximate date and time of the unexpected credit consumption. * What operation consumed the credits: inference calls, training, or batch processing. * Whether a known [platform incident](/support/roboflow-status-and-uptime.md) coincides with the consumption spike, and whether you saw errors at that time. * A screenshot of the usage dashboard showing the consumption spike. ## Data Privacy & Account Deletion Requests to [delete an account](/support/account-deletion.md) and all associated personal data (GDPR erasure requests), incomplete data deletion where images remain publicly accessible after account deletion, or requests to remove a specific project from public Universe. What helps most: * The email address of the account to be deleted. * Confirmation that all projects and workspaces have been deleted from within the account first, which is required before account deletion can proceed. * For GDPR requests: a statement of the legal basis for the request and a description of what data you believe remains accessible. * A link to any specific public Universe resource that should be removed, with an explanation of why. ## Security Issues An API key was accidentally exposed (ex: committed to a public GitHub repo or shared in a chat), or a security researcher found a vulnerability in the Roboflow platform. {% hint style="warning" %} If a key is exposed, immediately rotate it in your Roboflow workspace settings. Rotating invalidates the compromised key. Then notify support with the approximate time of exposure so we can audit for any unauthorized use. {% endhint %} For exposed keys, include: * Confirmation that the key has already been rotated. * The approximate date and time the key was exposed, and through what channel. * Whether there is evidence of unauthorized API usage during the exposure window. For vulnerability reports, email with a clear description of the vulnerability, reproduction steps, and the potential impact. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.roboflow.com/support/getting-help-faster-what-to-include-in-a-support-request.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.