Supported file types

logcat.ai accepts text-based system logs, a set of structured archives, and several binary capture formats it decodes for you: network captures, Bluetooth HCI snoops, SQLite snapshots, perfetto traces, automotive DLT traces, Qualcomm baseband captures, and gzip-compressed logs. Files are auto-classified at upload. Text logs are analyzed line by line; packet captures, traces, and databases are decoded and queried as structured data. You don’t need to label, decompress, or convert anything.

If you’ve tried to upload an image, a .dmg, or another binary and seen an error, this page explains why and what to send instead.

Accepted formats

Android bugreport archives

.zip Android bugreports. The standard adb bugreport output. Both flat zips (containing a bugreport-*.txt) and OEM-style nested zips (a bugreport zip wrapped inside another zip) are recognized.
Multi-zip uploads. You can upload more than one bugreport zip in a single batch. Each zip is validated independently; every archive in the batch must contain a valid Android bugreport.

Multi-file bundles

Log archives. A .zip, .7z, or tar archive (.tar, .tar.gz / .tgz, .tar.xz / .txz, .tar.zst / .tzst) that holds several logs is analyzed as a bundle: the platform unpacks the tree, classifies each file, analyzes them, and correlates across the set. Upload the archive as-is; there’s no need to extract it first. OEM megadumps and Qualcomm ramdumps are handled this way. The archive is recognized by its contents, so an unusual or missing extension still works.
Automotive board captures. A vendor dumpstate_board capture, an archive of the head unit’s DLT traces, QNX logs, network captures, and system traces (sometimes shipped with a .bin extension), is analyzed as a bundle. Each log inside gets its own analysis, and a screen capture recovered from the archive is shown on the dashboard.

Android text logs

logcat. Output from adb logcat, the Android Studio Logcat panel, and CI/CD log artifacts. Common buffer formats (main, system, radio, events, crash) and threadtime/brief/time formats are all detected.
JSON logcat exports. Android Studio’s structured JSON export.
ANR traces. traces.txt and per-incident ANR captures.
Tombstones. Native crash dumps from /data/tombstones/.
dumpsys output. Full or per-service dumps (e.g. dumpsys batterystats, dumpsys activity).
Event logs. logcat -b events output.

Linux text logs

dmesg. Kernel ring buffer output. All architectures supported: ARM, x86, MIPS, RISC-V.
Custom kernel logs. Vendor or board-specific kernel output, as long as it’s text.
syslog and journalctl exports. System daemon logs from any Linux distribution. journalctl --no-pager plain output works directly.
Application stdout/stderr. Text logs from services and daemons running on Linux devices.
QNX system logs. SLOG2 / slogger2 text output from a QNX real-time OS, common in automotive safety and instrument-cluster systems. Recognized as a structured log with its own severity levels.

Test artifacts

CTS / VTS / GTS / STS XML. Android Compatibility, Vendor, Google, and Security Test Suite result files.

Config files

Device and network configs. hostapd, OpenWrt UCI, firewall rules, and generic key-value config files are detected and analyzed alongside the logs they explain. A config uploaded with a capture from the same device gives the analysis the settings behind the behavior it sees.

CAN bus

candump traces. Text output from the open-source candump tool (Linux SocketCAN). This is the only CAN format auto-detected today. Captures from Vector CANalyzer, CANoe, or PEAK PCAN-View must be exported to candump-format text first; see Preparing automotive logs for the steps.
DBC files. These are uploaded separately through the References library in the console, not as a log. Once a DBC is registered, candump traces are decoded against it automatically.

Generic text logs

If you have a custom log format that isn’t listed above, upload it anyway. Unknown text formats are classified automatically and analyzed. This is how decoded vendor exports (telecom modem text, custom embedded logs) work.

Network and binary captures

These binary formats are decoded automatically at ingest. Upload them as-is, no conversion or decompression needed:

.pcap / .pcapng network captures. Decoded automatically and analyzed for network forensics: connection and protocol breakdowns, TLS/SSH fingerprints, and scan/beaconing/DGA threat signals, with a queryable dashboard. Deep Research and Quick Search can run SQL queries over the capture directly.
btsnoop Bluetooth HCI logs. Host-controller snoop captures, decoded automatically for analysis.
SQLite database snapshots. Decoded automatically. A snapshot can also act as a reference table that resolves opaque identifiers (device fingerprints, MAC addresses) in sibling logs from the same capture.
perfetto traces. Android/Linux system traces (.perfetto-trace, .pftrace, .perfetto). Search and Deep Research run SQL against the trace directly, and you get a dashboard.
DLT (Diagnostic Log and Trace). .dlt files and their .dlt.gz rotations, the AUTOSAR automotive logging standard. Decoded automatically into readable log lines that keep each message’s ECU, application, context, and level, so you can search and filter them by those fields like any other structured log.
gzip-compressed logs. A single-file .gz (e.g. logcat.gz, dmesg.gz) is transparently decompressed at upload; you don’t need to gunzip it first. (Multi-file archives like .zip and .tar.gz are handled as bundles, so you don’t need to extract them either.)
UTF-16 text logs. A log saved as UTF-16 (the usual result of redirecting adb logcat to a file on Windows) is transcoded automatically. No need to re-encode it first.
Linux kernel core dumps (vmcore). The core a crashed Linux machine writes, x86-64 or ARM64, uploaded exactly as your collector saved it, either the plain form or the compressed one most distributions produce by default (no need to expand it first; zlib-compressed captures are read directly, and a capture using another compression is rejected with a message saying so rather than analyzed incorrectly). You get the recovered kernel log, the machine’s kernel release and boot command line, the fault the kernel itself reported, and where each processor was when it went down, without uploading a debug image, because the dump describes its own layout. The recovered log also becomes a log of its own that you can read, search and analyze like any other. Uploading the matching kernel debug image to the References library adds the deeper symbol-level analysis on top. One caveat worth knowing before you capture: a dump taken from outside the machine (a hypervisor or cloud “dump this VM” action, which saves memory without the guest’s help) carries less for us to work from than one written by the machine’s own crash kernel. On x86-64 we still recover the log from it; on ARM64 that shape needs the matching debug image. If you can choose, an in-guest capture gives you more either way. See Kernel dumps & References.

Kernel symbols (References)

A kernel debug image is uploaded through the References library rather than as a log, and activates deep symbol-level analysis for every dump of that kernel build, Qualcomm ramdump or Linux core dump alike. Either form works: a full vmlinux, or the separate debug file your distribution ships for that kernel (often named vmlinux-<version> or ending in .debug, from a -dbg or -debuginfo package). Because these are far larger than the per-file upload cap, they take their own upload path.

Symbols are matched to a dump by build ID, so one upload covers every later dump of that exact build. A kernel version is not specific enough on its own, since a distribution ships many builds under one version: if the only image on file is a different build of the same version, the dump is analyzed without symbols and the analysis says so rather than using it. See Kernel dumps & References. A DBC file (CAN signal database, up to 10 MB) is registered the same way.

Not accepted

Binary files

The following are rejected when uploaded as a log. Common families:

Executables, libraries, and disk images: .exe, .dmg, .iso, .so, .dex, Mach-O. Two kinds of ELF file are the exception and both are accepted: a Linux kernel core dump (see below), and a kernel debug image (a vmlinux or your distribution’s separate debug file), which isn’t a log but belongs in the References library.
Raw memory images: a .bin on its own isn’t analyzable. The DDR and IMEM region blobs of a Qualcomm ramdump are .bin files, and they’re accepted inside the dump archive, where the manifests give them meaning. See Kernel dumps & References.
App-package archives: .jar and .apk. These are code packages, not logs. (Archives that hold logs, like .zip and .tar.gz, are accepted as multi-file bundles instead.)
Documents: PDF
Images: PNG, JPEG, RIFF

Vendor binary log formats

Qualcomm baseband captures upload directly. Both the block-container and the framed-stream form are decoded for you, with no conversion step and no vendor tool. Upload the capture as it came off the device.

You get the decoded measurements (serving and neighbour cell identity, signal strength and quality over time), the control-plane message exchange, and the modem’s own debug text, all queryable and searchable. You also get an analysis: signal quality on the cell the device was camped on, rejections and failed procedures in the signalling exchange, and a plain account of how much of the capture we could read.

Three things worth knowing before you read the results:

Records come back at three depths, and the analysis tells you how much of the capture landed in each. Some are fully decoded. Some are read in part, giving you what kind of record it is and any text carried inside it, but not every field. The rest are retained and searchable but not interpreted, because they are written in a vendor layout that is not published. A low fully-decoded share means we could not read those records, not that the capture was quiet.
Control-plane messages are reported twice over: how many were found, and how many we could identify. Not every message can be named. Some are ciphered, and some are of a kind we cannot route to a decoder, so the two numbers are given separately rather than presenting a partial exchange as a complete one.
Recognition is by content, not by file extension. A renamed capture still works.

Baseband analysis needs telecom analysis on your account. Without it the capture still uploads, decodes and is searchable, and the analysis step is skipped. Talk to us if you need it enabled.

Other vendors’ binary captures still need a text export first:

Telecom (other vendors): .mcl (MediaTek), and Samsung Shannon CP dumps, which are often saved as .hdf and are a different format from the Qualcomm capture that shares that extension. Nothing here is decided by the extension, so upload what you have rather than guessing. See Preparing telecom logs.
Automotive CAN: .blf, .asc, .trc, .mf4. Convert to candump-format text first; see Preparing automotive logs.

Why a file gets rejected as binary

Apart from the binary formats it explicitly decodes (see Network and binary captures above), a file is treated as a log only if it’s predominantly printable text. A file that isn’t a recognized binary capture and carries a high share of non-printable content is treated as binary and rejected. If a text log is wrongly rejected, export a clean text version and re-upload.

Empty files

A file with no content is rejected at upload. 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.

Files that aren’t diagnostic

A text file is also rejected if it isn’t a log, trace, dump, capture or configuration at all. A saved article or web page kept for reading, a contract or invoice, a spreadsheet of business figures, a slide deck: these are perfectly valid files, and there’s nothing in them for the analyzer to read.

What counts is what the file records, not the format it arrives in. A recording of a system’s behaviour is accepted whatever container it came in, so an HTTP archive of a browser session and a diagnostics page saved out of a browser both qualify, even though both are web formats.

If a real log is rejected this way, reply to the upload and we’ll take a look. It’s the case we most want to hear about.

Prepare before upload

Pick the guide for your system:

Size limits

Two separate limits apply:

Per file: 250 MB by default, the same for every account. This covers the vast majority of bugreports, bundles, and long-running captures. Kernel debug images are exempt, in either form (a full vmlinux or your distribution’s separate debug file): they go through the References library, which takes large uploads.
Total storage: how much uploaded data you can hold at once is set per account. Your billing page shows your allowance and what you’ve used. See Plans & pricing.

One more limit applies to compressed kernel crash dumps only. These are expanded back to the memory they describe before anything can read them, so a small file can need a great deal of room. A capture whose expanded memory is larger than we can hold is refused with a message saying so, rather than failing partway through. If you hit this, get in touch. The limit comes from the environment your account runs in rather than from your file, and a self-hosted install can raise it.

Multi-file uploads

You can upload several files in a single batch. Each file is classified and validated on its own:

Multi-zip bugreport batches: every archive must independently contain a valid Android bugreport.
Mixed-format batches: for cross-file investigations (e.g. a bugreport plus a kernel dmesg from the same device), see Delta Comparison.