Troubleshooting

The most common snags, and what they mean.

My upload was rejected

The platform validates every file at ingest. A rejection usually falls into one of these:

It’s a binary the platform doesn’t decode. Executables, images, PDFs, and disk images are rejected. Note that several binary formats are accepted and decoded directly (pcap/pcapng, btsnoop, SQLite, Linux kernel core dumps, Qualcomm ramdumps, and Qualcomm baseband captures), so if you’re sending one of those, you don’t need to convert it. See Supported file types.
It’s a proprietary vendor trace in native form. MediaTek modem captures (.mcl), Samsung Shannon CP dumps, and binary CAN traces (.blf, .asc, .trc, .mf4) must be exported to text first. Qualcomm baseband captures are not in this group: they upload as they came off the device, in either container form, whatever the extension says. See Preparing telecom logs and Preparing automotive logs.
A text file has too much non-printable content. The platform accepts files that are predominantly printable text; files with null bytes or a high share of non-printable content are rejected as likely-binary. Export a clean text version and re-upload.
The file is empty. A file with no content is rejected. Usually the capture was still being written when it was copied, or the export finished with nothing in it. Check the file has a size on your machine, then upload it again.
You hit a limit. Storage full, or the file exceeds your tier’s size cap. See Why was I limited?.

Single-file .gz is fine. It’s transparently decompressed, so you don’t need to gunzip first.

Only part of my capture could be read

A capture that stops partway through, because the recording tool was still writing it or the transfer was cut short, is still analyzed. You get everything up to the point it stopped being readable, and the analysis tells you it ended early.

Counts in that analysis are a floor rather than a total. If it reports 400 of something, there were at least 400, and there may have been more in the part that could not be read. Keep that in mind when comparing two captures, since one of them may simply have been read further than the other.

If you need the complete picture, export the capture again once the recording has finished, then upload it.

Analysis is stuck at “Visualizing”

Not a hang. Visualizing is the last step: the analysis is done and your dashboard is being built. It flips to completed on its own in a moment, with the dashboard ready.

If it’s genuinely stuck for a long time, or shows Failed, a failed analysis can be retried (up to a few attempts). Re-run it; if it keeps failing, email support@logcat.ai with the file.

The analysis returned no results

Check the file wasn’t capability-blocked. Telecom, automotive, and kernel-dump logs need the matching capability on your account; without it the file uploads but analysis stops. See Why was I limited?.
Wait for the dashboard. If the file is still Visualizing, the charts and findings aren’t ready yet (above).
Ask a more grounded question. If search comes back thin, anchor the question to a symptom, subsystem, or time window rather than asking “what’s wrong?” See Deep Research for prompt tips.
Check the file has the signal. A capture that doesn’t contain the event you’re asking about won’t surface it. Confirm the window you captured actually covers the failure.

Still stuck?

Your billing page shows your live plan, limits, and reset dates. For anything else, email support@logcat.ai.