A bug rarely lives in one file. A real capture is a hundred files in a dozen formats, and each holds one piece of the identity: the build in one, the kernel in another, the device in none of them alone.
Drop the whole archive. logcat.ai reads every line item, reconciles one device, one build and one clock, and cites each fact back to the file that stated it.
Seven of these twelve files keep their own clock, in five regimes. Read one at a time, a fault at 09:12 in one file and at boot+1284 s in another is never seen as the same instant.
Twelve files, twelve clocks. One device, one timeline.
One question, answered across the whole bundle.
126 files, one situation. The investigation rules out the obvious causes, decodes the CAN trace through the bundle's own signal database, and lines up three files on one timeline to name a root cause none of them shows alone.
Every step cites the line item it read. The answer is a cross-file root cause, not a summary of one log.
thermal throttling
low-memory killer
06telematics_radio.log
07vehicle_hal.txt
One identity, findings rolled up.
Before any question is asked, the bundle is reduced to a single reconciled identity (sheet 1) and a roll-up that shows which findings recur across how many files.
The fault shows in the CAN trace, the timeout in the modem log, the disconnect in the HAL. Only together do they name a root cause, and the roll-up is where they first meet.
The archive decodes itself.
Logs are full of raw IDs (CAN arbitration codes, MAC addresses, symbol offsets) whose meaning lives in a separate reference file you cross-reference by hand.
When the bundle carries that file, logcat.ai matches it to the siblings whose raw IDs it resolves, verified by value overlap, and turns opaque codes into named signals and devices.
Charts the whole bundle makes.
Auto-generated across files: the composition of the archive, and a roll-up where one file reading zero is itself the clue, every value traced back to a leaf.
The dashboard reads the bundle's structure and what's breaking across files, then draws the charts that fit: composition, and findings by file.
The story lives between the files.
The story lives in the relationships between files, not in any single log. Reading them one at a time is how cross-component bugs hide.
Each difficulty below is a line on the manifest that a person has to reconcile by hand, and each is charged again for the next engineer who opens the same archive.
A real capture is a hundred files in a dozen formats. Opening them one by one means never seeing how they line up.
Logs are full of raw IDs (CAN arbitration codes, MAC addresses, symbol offsets) whose meaning lives in a separate reference file you cross-reference by hand.
Which device? Which build? Which window? The answer is spread across a dozen files, each holding one piece.
The fault shows in the CAN trace, the timeout in the modem log, the disconnect in the HAL. Only together do they name a root cause.
Opening a hundred files one at a time, holding the timeline in your head.
Cross-referencing raw IDs against a separate database, row by row.
Reassembling one device's identity from a dozen scattered files.
Missing the cross-component pattern because no single file shows it.
Re-deriving all of it for the next engineer who picks up the bundle.
A correlation engine over the whole archive.
A correlation engine over the whole archive, rather than a file viewer. Four things it does with a consignment, and the sheet on which each one is written.
One device, build, and time window assembled from every file in the bundle, each fact cited back to the file it came from.
The archive's own reference files (a CAN signal database, a device-fingerprint table, a symbol map) automatically decode the opaque IDs in their sibling logs.
Every leaf is analyzed, then findings roll up across the bundle: "this fault in 3 of 126 files", with charts no single file can produce.
A gigabyte and a hundred-plus mixed-format files as one investigation: rotations collapsed, the whole bundle asked as a single question.
What counts as a bundle.
Any archive that captures one situation across many files: the support bundle, diagnostic dump, or device snapshot your team already collects. logcat.ai recognizes the shape and reads it as a whole.
Inside a .zip, .tar, .tar.gz, .tar.xz or .tar.zst. Nested archives (a bugreport zip inside an outer archive) are recognized and expanded.
A vendor bugreport plus dozens of app logs, dumpsys, and framework traces from one device.
Access-point logs, per-radio configs, a roaming daemon, and a client-fingerprint database.
CAN traces, a DBC signal database, telematics and vehicle-HAL logs from one drive cycle.
A panic dump alongside rotated dmesg and last-kmsg from the boot that died.
A dozen numbered logcat segments the system collapses back into one stream.
An index that fans out to many per-result files, read through its manifest.
How an archive reaches you.
An archive is what an incident leaves behind. Three shapes that pile arrives in, and the sheet of the manifest that answers each.
A hundred logs, configs, and dumps from one incident, and no idea where to start. The investigation on sheet 2 read all 126 together and named a cross-file root cause: cited, on one timeline.
Raw CAN codes, MAC addresses, symbol offsets: meaningless without the reference file next to them. The bundle's own databases decode them automatically, into named signals and devices. Upload an access point's files together and its clients stop being hardware addresses: you get them ranked by activity and by disconnects, and split by device type and client operating system, each resolved to a real device. A candidate that resolves nothing is not used, so what you see are real matches.
You want the shape of the whole capture, not a hundred open tabs. The dashboard reads the bundle's structure and what's breaking across files, then draws the charts that fit: composition, and findings by file.
Cross-file bundle analysis, answered.
Six questions engineers ask before they drop in a real archive, each answered as it stands today.
Any mix of files, logcat, bugreports, dmesg, CAN traces, Perfetto, pcap, configs, and reference databases (DBC, SQLite, fingerprint tables), inside a .zip, .tar, .tar.gz, .tar.xz, or .tar.zst. Nested archives (a bugreport zip inside an outer archive) are recognized and expanded.
Each file is analyzed on its own, the bundle's structure and one reconciled identity are computed, and reference files are matched to the siblings whose IDs they resolve, verified by value overlap, not guessed. Deep research and the dashboard then query the whole bundle at once.
When the archive carries a reference file (a CAN signal database, a device-fingerprint table, a symbol map) logcat.ai uses it to decode the opaque identifiers in its sibling logs automatically. A DBC turns CAN arbitration IDs into named signals; a fingerprint table turns MAC addresses into device and OS.
Comfortably a gigabyte and a hundred-plus files in one investigation. Rotated logs are collapsed into groups, and very large bundles are triaged so the files that carry signal are analyzed first.
No. Single files work too, and each has its own analyzer. A bundle is for when the answer lives across files; you get the cross-file correlation only an archive can provide.
Your bundle data is encrypted in transit (TLS 1.3) and at rest (AES-256), processed in your own tenant, and never used to train AI models. The cross-file reasoning derived from a bundle stays isolated to your enterprise. Files are deleted after 90 days, or immediately from your dashboard. Enterprise plans offer on-premise deployment for regulated or air-gapped environments.
The fastest way to see cross-file correlation is to drop in an actual diagnostic archive (a bugreport plus its siblings, an AP snapshot, a drive-cycle capture) and watch one cited answer come back from all of it.