Supported file types
logcat.ai accepts text logs, archives of logs, and a set of binary captures it decodes for you. Every file is recognized from its contents, not its extension, so you don’t need to label, convert, rename, or decompress anything first.
Android
| Format | Notes |
|---|---|
Bugreport .zip | The standard adb bugreport output, flat or OEM-nested. Everything inside gets its own results. |
| logcat | adb logcat, Android Studio, CI artifacts. All buffers and all output formats are detected, including Android Studio’s JSON export. |
| ANR traces, tombstones | traces.txt, per-incident ANR captures, /data/tombstones/ dumps. |
dumpsys output | Full or per-service dumps. |
| CTS / VTS / GTS / STS results | Test suite XML result files. |
Linux and embedded
| Format | Notes |
|---|---|
dmesg and vendor kernel logs | Any architecture. |
syslog, journalctl exports | Any distribution; plain journalctl --no-pager output works directly. logread lines, and syslog lines stamped with a full date and a facility and level, are read with their timestamps, levels and daemon names; classic syslog lines with their timestamps and daemon names. |
| Serial console captures | Syslog or logcat saved by a PC terminal that stamps each line. See Preparing embedded and IoT logs. |
| Application stdout/stderr | Text logs from services and daemons. |
| QNX SLOG2 | slogger2 text output. See Preparing automotive logs. |
| Config files | hostapd, OpenWrt UCI, firewall rules, generic key-value configs. Analyzed alongside the logs from the same device. |
| Unknown text formats | Upload them anyway. Unknown text is classified and analyzed. |
See Preparing embedded and IoT logs.
Archives and bundles
| Format | Notes |
|---|---|
Log archives. .zip, .7z, .tar, .tar.gz, .tgz, .tar.xz, .txz, .tar.zst, .tzst | Analyzed as a bundle: every file inside is classified and analyzed, and findings are correlated across the set. OEM megadumps, device ramdumps, and automotive board captures all arrive this way. |
Single-file .gz | logcat.gz, dmesg.gz, .pcap.gz, .dlt.gz and the like are decompressed transparently. |
| UTF-16 text | The usual result of redirecting adb logcat on Windows. Transcoded automatically. |
| Emails and saved web pages | .eml, .mbox, .mhtml. A log inside is read without extracting it first. |
Decoded binary captures
These upload as-is and are decoded for you. Packet captures, traces, recordings, databases and kernel dumps are queried as structured data; the rest become searchable log lines.
| Format | Notes |
|---|---|
.pcap, .pcapng | Network forensics with SQL over the capture, plus the radio layer for monitor-mode captures. See Network captures. |
| btsnoop | Bluetooth HCI snoop logs. |
| SQLite snapshots | Also act as a reference table that resolves identifiers in sibling logs from the same capture. See SQLite and btsnoop. |
| perfetto traces | .perfetto-trace, .pftrace, .perfetto. SQL queries and a dashboard. See Perfetto traces. |
| DLT | .dlt and .dlt.gz, the AUTOSAR trace standard, decoded into structured log lines. See Preparing automotive logs. |
| candump | Text output from Linux SocketCAN candump, including CAN FD frames, remote requests and error frames. See Preparing automotive logs. |
| Vector ASCII CAN traces | .asc, read as exported: classic CAN, CAN FD, remote requests, error frames and 29-bit extended identifiers, with markers and comments skipped. See Preparing automotive logs. |
| Vector binary CAN logs | .blf, read as recorded: classic CAN and CAN FD messages, remote requests and error frames, with their timestamps. See Preparing automotive logs. |
| DTS diagnostic traces | .trc files whose first line is [Description], read as recorded. A .trc written by PCAN-View is a different format and needs a text export. See Preparing automotive logs. |
| Qualcomm baseband captures | Both the block-container and framed-stream forms, decoded without a vendor tool. See Preparing telecom logs. |
| ROS recordings | .bag, .mcap, .db3. Upload the storage file, or zip a ROS 2 recording folder so a multi-file run is read as one recording. See Robot recordings. |
| Linux kernel core dumps | vmcore, plain or zlib-compressed, x86-64 and ARM64. The first analysis tier needs no debug image. See Kernel dumps. |
| Qualcomm ramdumps | The collector’s archive of region blobs and manifests, in any archive type. See Kernel dumps. |
| Ramdump parser reports | The text report the Linux ramdump parser prints for a ramdump, split into its sections so each can be read on its own. Each of its kernel log, logcat and journal sections that holds the device’s log lines is analyzed as its own log beside the report. |
| Flash and persistent kernel crash records | mtdoops flash-partition crash dumps and pstore/ramoops persistent crash records, decoded into the kernel panic, oops or BUG and its call stack. Each stored crash is kept separate. See Kernel dumps. |
Automotive, telecom, robotics and kernel dump analysis each need a capability on your account. See Why was I limited?.
References, not logs
Five file kinds are uploaded through the References library in the console rather than as a log, because they describe other files rather than recording anything themselves:
- Kernel debug images, a full
vmlinuxor your distribution’s separate.debugfile. See Kernel dumps. - Kernel modules, the
.kodebug object for a loadable driver, one file per module. See Kernel dumps. - DBC files, the CAN signal database (up to 10 MB). Once registered, every CAN trace format above is decoded against it. See Preparing automotive logs.
- Modem message databases (
.qsr4, up to 64 MB), which restore the compressed debug messages in a baseband capture. See Preparing telecom logs. - Modem firmware images (
.elf, up to 1 GiB), which name the firmware function behind trace messages whose text the vendor did not ship. See Preparing telecom logs.
Not accepted
| What | Why, and what to do |
|---|---|
MediaTek .mcl, Samsung Shannon CP dumps | Proprietary encodings. Export to text with the vendor tool first. See Preparing telecom logs. A Samsung .hdf is a different format from the Qualcomm .hdf that uploads directly; you don’t need to tell them apart, just upload it. |
CAN .mf4, and .trc files written by PCAN-View | Convert to candump text first. See Preparing automotive logs. |
| Executables, libraries, disk images, app packages | .exe, .dmg, .iso, .so, .dex, .apk, .jar. Code, not logs. |
A raw .bin on its own | Not analyzable outside the dump archive that gives it meaning. |
| Documents and images | PDF, PNG, JPEG, RIFF. |
| Empty files | Usually a capture copied while it was still being written. Check the size and upload again. |
| Text that isn’t diagnostic | An article or web page saved for reading, a contract, a spreadsheet, a slide deck. What counts is what the file records, not its format: an HTTP archive of a browser session and a diagnostics page saved out of a browser are both accepted. If a real log is refused this way, reply to the upload and we’ll look. |
Apart from the binary captures listed above, a file is read as a log only if it is predominantly printable text. A file with a high non-printable share is rejected as binary; export a clean text version and upload that.
Size limits
- 250 MB per file by default, for every account.
- Formats that are large by nature get a higher ceiling, because trimming one means throwing away the evidence. The exemption is decided from the file extension, so it applies to these and only these:
.7z,vmcore,vmcore-dmesg,core,dump,.vmcore,.core,.kdump,.bag,.mcap,.db3,.perfetto-trace,.pftrace,.perfetto,.pcap,.pcapng,.qmdl,.qmdl2,.hdf,.sdm,.dlt,.blf,.asc(including a.gzform of any of them). They are still bounded, just not at 250 MB. - Because that is decided before any bytes move, repacking a large capture into a
.zipor.tar.gzgives up the exemption, and a recording saved without its extension takes the ordinary limit. - Kernel debug images go through the References library, which takes large uploads: up to 1 GiB (1,073,741,824 bytes) per image, whether it is uploaded from the References tab or shipped inside a dump archive. A larger image is refused with a message saying so; upload the
vmlinuxor the separate debug file alone, never a whole build tree. The images inside one archive share a per-upload allowance, and an image past it is not added to the library. - 200 files to analyze per archive, nested archives included. Rotated copies of one log count once, a kernel dump’s region files and a robot recording folder each count once, and images, app packages, empty files and system clutter don’t count. A bugreport counts as each analysis it produces: the bugreport itself, its system and kernel logs, and its crash and ANR records. That holds for a bugreport text file under any name and for a
.zipwhose name starts withbugreport; a bugreport.zipunder another name is opened like any other archive, so each file in it counts. A ramdump parser report counts the same way: the report itself and each device log analyzed from it. An archive over the limit is refused with a message saying so and nothing in it is analyzed; split it into smaller archives. - 10,000 files per archive in total, counting the files inside archives within it, and 16 GiB to unpack one, the archive included. A larger one is refused before unpacking.
- 500 MB for a bugreport’s main report, expanded. A bugreport
.zippast that, even inside an archive, is listed as too large to process; nothing in it is analyzed or charged. Upload its logs as separate files. - A compressed kernel crash dump is expanded before it is read. One whose expanded memory exceeds what the environment can hold is refused with a message saying so; a self-hosted install can raise that limit.
- Total storage is set per account and counted by the data an archive holds, not its compressed size. Your billing page shows the allowance and what you’ve used. See Plans & pricing.
Multi-file uploads
Upload several files in one batch. Each is classified and validated on its own. For cross-file investigations (a bugreport plus a kernel log from the same device), see Delta Comparison.