This guide covers the most common problems when importing data into Label Studio or syncing a source storage: data that never appears in the Data Manager, the wrong number of tasks being created, large imports that time out, and import/parse failures. Each symptom below lists the likely cause and the steps to resolve it.

The Data Manager is empty after importing or syncing

If the import or sync appears to finish but no tasks show up, work through the following.

1. Confirm the job actually ran. Both UI/API imports and storage syncs run as background jobs. If nothing happens for a while, the job may be queued or the workers may be down. On self-hosted deployments, sign in as a superuser and open the /django-rq page. Check the Workers column — if it shows 0 or is empty, your RQ workers are not running and no import/sync work can complete. Restart the rqworker containers with your DevOps team, then retry. You can also open Failed jobs on that page to read the error for a specific job.

2. Check the import method for source storage. When you sync a cloud bucket, the storage connection must be configured with the correct import method: - Use Files (older UI: enable Treat every bucket object as a source file) when the bucket holds raw media (images, audio, text, etc.). Label Studio then lists each object and builds one task per file. - Use Tasks — "Treat each JSON, JSONL, or Parquet as one or more task definitions per file" (older UI: disable Treat every bucket object as a source file) when the bucket holds Label Studio JSON/JSONL/Parquet task files. Label Studio then parses each file into tasks.

Choosing the wrong method is the most common reason a sync "succeeds" but the Data Manager stays empty. In particular, if Treat every bucket object as a source file is left ON while your bucket holds task JSON/JSONL, Label Studio imports each file as one opaque media object instead of reading the tasks inside it.

3. Verify the File Filter Regex. For source storage, if no filter is set, all found items are skipped. The filter must be a valid regular expression, not a shell wildcard — for example .*\.jsonl$ is valid, but *.jsonl is not.

4. Rule out a read-permission problem (bucket shows no tasks). As a quick diagnostic, edit the storage and temporarily enable Treat every bucket object as a source file. If tasks now appear but disappear when you turn it back off, your bucket likely has LIST permission but not GET permission. Label Studio can list objects to count them, but it needs GET to actually read and parse your JSON files into tasks. Grant read/GET access and re-sync.

"No tasks available" even though the task count is not zero

If the project shows No tasks available but the status bar still reports a non-zero count (e.g. Tasks: 0 / 350), your data is not gone — the Data Manager itself is failing to render. In review-enabled projects this is often an Agreement/consensus computation error rather than a data problem. A representative backend error is:

index 2 is out of bounds for axis 0 with size 2

This happens when the precomputed agreement score matrices are stale or out of sync with the current annotations — typically after annotations were deleted, edited, or re-imported, the labeling configuration changed, or an agreement backfill ran only partially. One bad task can blank the entire view.

To get back into your data:

1. Click the + next to the Default tab to create a new tab/view.
2. In the new tab, remove any Order by on an Agreement column and remove any Agreement filter.
3. Use Columns to hide the Agreement column(s).

If the new tab loads the tasks, the agreement computation is the trigger and your data is safe. The permanent fix is to recompute (backfill) the agreement matrices for the project — submit a ticket with your project ID so support can trigger it.

The wrong number of tasks was created

Label Studio decides how many tasks to create based on the shape of your data.

One task was created instead of many

• JSON must be a list to create multiple tasks. A JSON array creates one task per element:

json [ {"data": {"my_text": "First task"}}, {"data": {"my_text": "Second task"}} ]

If there is no data key, Label Studio interprets the entire JSON file as a single task. A common mistake is importing one big object (or a dict keyed by ID) rather than a list of task objects.

CSV/TSV or plain text produced unexpected tasks

• For CSV/TSV, Label Studio treats the column names as task data keys. Those keys must match the variables in your labeling config object tags (e.g. a column named my_text maps to <Text value="$my_text"/>). Mismatched or misspelled columns lead to empty or unusable tasks.
• For plain text files, Label Studio treats each line as a separate task. An unexpected line count usually means stray newlines or a file that should have been imported as JSON/CSV instead.

Syncing created extra/duplicate tasks

If re-syncing a source storage (especially after an export to that same bucket) creates extra tasks that can't be annotated:

• Keep source (import) and target (export) storage in separate buckets/folders. When exported annotation files land back in the source bucket, a later sync picks them up as new "tasks."
• If you imported the bulk of your tasks through the SDK/API and only keep the cloud storage attached to host/resolve media, do not click Sync on that storage — syncing can create duplicate tasks. Attach it for URL resolution only.

Large imports or syncs time out (partial import)

A very common cause of a sync that "fails" but still imports some tasks is a background job timeout, not bad data. The tell-tale sign is that each time you click Sync, more tasks appear (storage sync is idempotent and resumes where it left off). Real errors seen on the failed job include:

rq.timeouts.JobTimeoutException: Task exceeded maximum timeout value (10800 seconds)

or

It appears the job was failed because the last ping time is too old

(the sync worker must send a periodic health "ping"; if it doesn't update within the internal window, the job is marked Failed even while still working).

Resolutions:

1. Split the data into smaller files/batches. Instead of one large JSON with tens of thousands of tasks, break it into multiple smaller files (roughly a few thousand task definitions each) in the bucket, then sync. Each file is processed as independent work, so no single job runs long enough to time out. This is usually the biggest win.
2. Sync one prefix at a time. Organize files under prefixes (batch_01/, batch_02/, …) and point the File Filter Regex at a single batch (e.g. batch_01/.*\.jsonl$), confirm the count, then move on.
3. For a one-off bulk load, import in chunks via the SDK/API instead of storage sync. This avoids the long-running sync job and lets you control batch size. Keep the media in cloud storage referenced by URL; only the task JSON is imported.

```python import os, json from label_studio_sdk import LabelStudio

ls = LabelStudio(base_url=os.getenv("LABEL_STUDIO_URL"), api_key=os.getenv("LABEL_STUDIO_API_KEY"))

PROJECT_ID = 12345 with open("tasks.jsonl") as f: tasks = [json.loads(line) for line in f]

BATCH = 2000 for i in range(0, len(tasks), BATCH): ls.projects.import_tasks(id=PROJECT_ID, request=tasks[i:i + BATCH]) ```

4. Do not re-trigger Sync while a job is still running. Overlapping runs cause extra retries, confusing UI state, and can create duplicate tasks. Note that task creation is sequential, not parallel.
5. Self-hosted only: raise the RQ job timeout (e.g. the RQ_TIMEOUT environment variable in your Helm values) and give the rqworker pods more memory — large payloads (for example brush-mask predictions) are memory-hungry and can be OOMKilled mid-sync. On SaaS, submit a ticket with your project ID and the exact failed-job error so support can raise the sync timeout for your org.

Import fails or throws an error

1. Validate the file format and extension. Label Studio recognizes specific extensions per data type, including images (.bmp, .gif, .jpg, .png, .svg, .webp), audio (.flac, .m4a, .mp3, .ogg, .wav), video (.mp4, .webm), text/markup (.txt, .html, .htm, .xml), structured data (.csv, .tsv), and Label Studio tasks (.json; .jsonl and .parquet for cloud/enterprise). An unsupported or mislabeled extension is rejected before tasks are created.

2. Check for malformed JSON. Trailing commas, single quotes, or a truncated file will cause the parser to fail. Validate the file in a JSON linter before re-importing.

3. Respect the UI import limits. Direct UI import supports files containing up to 250,000 tasks or up to 50 MB in size. Larger files should be split, or the data should be connected through cloud storage instead.

4. Don't rely on the UI for production media. Uploading media files (images, audio, video) directly through the import UI is intended only for small/test projects — Label Studio does not provide full hosting or backup for those files. For real workloads, host media in cloud storage and import task JSON that references the media by URL.

Tasks show "Failed to load" or ?not_uploaded_project_file

If previously working tasks suddenly show Failed to load and the exported value carries a ?not_uploaded_project_file marker (for example upload/269482/af298cfb-...pdf?not_uploaded_project_file), the underlying uploaded file can no longer be resolved.

• One known trigger on UI-uploaded files: clicking Cancel in the Import dialog on an existing project can delete the file uploads listed there — including files from previous completed imports — which orphans those tasks. The annotations survive, but the source file reference no longer resolves. To leave the Import dialog safely, close it with the window close (X) control or navigate away rather than clicking Cancel.
• Recovery: re-upload the affected source files, then update each task's data reference to the re-uploaded file and re-import.
• Prevention: for production projects, host documents/media in cloud storage as a source storage so task references resolve against the bucket and cannot be orphaned by the UI.

Imported annotations or predictions don't show up

If tasks import correctly but their pre-annotations are missing, the predictions/annotations payload almost always doesn't match the labeling configuration.

• Each task can include predictions and annotations arrays as top-level keys alongside data. Do not nest predictions inside data, or they will be treated as plain task data instead of real predictions.
• Every entry in a result array must include from_name (a control tag name), to_name (the object tag it points to), type, and value.
• The from_name and to_name values must exactly match the name attributes in your labeling config. If they don't, Label Studio cannot map the region and the prediction simply won't render — often with no visible error.

Import via API or SDK

When importing programmatically, tasks are created through:

POST /api/projects/{id}/import

The same format rules apply: send a JSON list to create multiple tasks, ensure each object's data keys match your labeling config, and confirm the request succeeds (a non-2xx response returns the parse/validation error in the body). If the API returns success but tasks are missing, check the RQ workers and failed jobs as described above, since large imports are processed as background jobs.

Still stuck?

If you have worked through the relevant steps above and data still isn't importing or syncing as expected, submit a ticket. Include:

• how you imported (UI, API/SDK, or storage sync) and the file format,
• a small sample of the input file,
• the exact error text or job error from the storage card's red Failed status (or from Failed jobs on /django-rq for self-hosted),
• your project ID and whether you are on SaaS or self-hosted,
• and the approximate time you launched the import or sync job.

Related documentation

• Import data into Label Studio
• Understanding the Label Studio JSON format
• Import pre-annotations and predictions
• Sync data from cloud storage