Changelog

Notable changes to logcat.ai : new supported formats, new capabilities, and behavior that affects how you use the platform. Newest first.

2.8.0 (2026-08-21)

Breaking

A capture whose analysis we could not start now says so instead of reporting finished. When something on our side stopped a network capture, trace, kernel dump or baseband capture from ever being queued for analysis, the file used to settle as COMPLETED, which told you we had analyzed your capture when we had never looked at it. The structural read of the file was there, but the analysis you were owed had silently not happened and nothing on the file said so. It now reports FAILED with a message saying we could not start the analysis and to run it again. This is not applied backwards, so a capture already sitting in the old state keeps it: if you have one that finished suspiciously empty, upload it again.
A file with no bytes in it is refused at upload, and a large upload is measured rather than declared. Uploading a zero-byte file now answers 400 with a message telling you to check the capture finished writing. Before, it uploaded successfully and produced a finished-looking analysis of nothing. If your integration submits files straight off a device or an export tool, you may now see a 400 where you previously got a 201, and the file is the thing to check rather than the request. The documented 400 on the upload route now covers a missing, empty or unsupported file. Separately, a large upload’s size is now measured from what actually landed rather than taken from the size your client declared at the start. That measured size is what the file list and the reported file size show, so a client that under-declared will see honest figures now. It also sets what a plain file costs against your storage allowance; a compressed file or an archive is charged for what it holds once expanded, as it was before.
A text file that is not a log, trace, dump, capture or configuration is refused instead of analyzed. A text file whose content is the document itself rather than a recording of anything, a saved web page kept for reading, a plain-text contract, a data export that is a table of business figures, source code, is now turned away at upload with a message saying so. Before, a text file with a plausible structure was taken in and charted like a device log, and produced a dashboard about something that could never yield an answer. What counts is what the file records, not the format it arrives in, so a recording of a system’s behaviour is accepted whatever container it came in. A file inside an archive is skipped rather than refusing the whole upload. This is a judgement about your file’s content, so it can be wrong: if a real log is turned away, send it to us and we will look at it. That is the case we most want to hear about.

New

A finished file now tells you why it has no results. A file can finish successfully and still have nothing to show, because there was nothing in it to analyze. The response now carries content_outcome saying which of three it was: empty (no usable content: either no bytes at all, or bytes that decoded to nothing), unreadable (there was content, but it could not be read into anything analyzable), or none_analyzable (read fine and held nothing analyzable, often a capture over a quiet period). content_detail carries the same answer as a sentence you can show a user. Both are absent on an ordinary analysis, so treat their presence as the signal. No status value changed and none was added, so your polling loop does not need restructuring, but do not treat these fields as a terminal marker on their own: one of them is settled part way through, so you can see it while a file is still analyzing. If you render results in your own interface, read content_outcome before showing an empty state, because a finished file with nothing in it and a file we failed to process used to look identical over the API. Not every file answers yet. Network captures, traces, kernel dumps, baseband captures and multi-file bundles carry no outcome for now, and neither does anything processed before this shipped.
A kernel crash dump opens with the kernel’s own last words, and shows four more things when a debug image is on file. Every dump now leads with the first fault line quoted exactly as the kernel wrote it, with our reading of it beside rather than instead of it. Upload a matching debug image to the References library and the dashboard also shows four things it did not show before: the crashing task’s call chain, which is the one backtrace out of the hundreds in a dump that describes the crash rather than a task that happened to be asleep during it; the tasks genuinely blocked waiting on something, each with what it was waiting in, and with threads parked in that state by design left out so the list stays short; how much of the preceding ten seconds, minute and five minutes the machine spent stalled waiting for processor, memory or storage, which is the only figure in a dump describing the period before the capture rather than the instant of it; and what memory was holding at the moment it was taken. Each processor also gets its own tile now instead of a row in a table. The crashing task’s chain and the per-processor state need the registers a Linux core dump saves, so a device ramdump reports them as not available rather than as an empty result, and gains the other two. A call chain says how it was read, and one recovered by scanning the stack is shown unnumbered, because the order of those addresses is not a call order. A dump uploaded on its own now carries the most important of these on its capture page as well. The readings behind them are more accurate in this release too, described separately under Fixed. Results are computed once and stored, so upload a dump again to get all of this, or re-run it if you have since added its debug image. See Kernel dumps.
The console has a light theme. You can now use the console on a light background. Switch it from the icon at the bottom of the left rail, from the bar at the bottom on a phone, or from Settings, where it sits next to your language. Dark stays the default for every account, so if you like the console as it is you do not need to switch. The dark dashboard improved too: the smallest labels (chart axes, table headers, timeline ticks) were too faint to read comfortably, and they are now a step brighter. Your choice follows your account rather than the browser you made it in, so signing in on a second machine gives you the same theme without setting it again. It is also applied before the page draws, so you will not see a dark flash on the way in. The whole console moved, not just the shell: dashboards, charts, the log viewer, investigations, uploads and the admin surfaces. Printed and exported reports stay on a light page in either theme, as they always have.

Changed

Capability messages name what you can actually ask for. When analysis stops because your account does not have the capability a file needs, the message now names it the way you would ask for it: telecom log analysis, automotive log analysis, kernel crash dump analysis, or API access. It previously used our internal word for it, which was worst for kernel crash dumps, where an engineer uploading a Linux server core was told they needed the ramdump capability, a term that named neither the file they sent nor anything anyone could grant them. The same wording is now used on the refusal itself, on uploads to the References library, and on the plans and limits pages. What your account holds has not changed, and if you read the capability list through the API the values there are unchanged.
A closed access period now stops analysis, not just new uploads. When an account’s access period has ended, or has not opened yet, it already blocked new uploads and new investigations. It now also stops analysis of files the account already holds, including a re-run of one that was analyzed before. Those files report PLAN_RESTRICTED, with a message giving the date your access ended or the date it begins and telling you to contact your administrator. The most likely way to meet this is uploading a debug image and re-running the analyses it unblocks after the period has closed. Several other entries in this release ask you to upload a file again to pick up a correction; if your period has closed, that is refused too, and the message will say so rather than describing the correction you were after. An active paid subscription still overrides a closed period exactly as it does for uploads, and nothing changes while your period is open. If you poll, expect to see PLAN_RESTRICTED on a file you had previously seen progressing.

Fixed

can_retry no longer tells you to keep waiting for a retry that was never scheduled. When a log or bugreport failed in a way that meant its analysis was never going to be queued, the file reported can_retry: true. Our documentation tells you that means the platform may recover it on its own and you should keep polling, and for this class of failure nothing was ever going to pick it up. It now reports can_retry: false, which our documentation defines as terminal, so your loop stops and you know to submit the file again. If you built a keep-polling loop on can_retry: true, this is the case where it could wait forever. Existing files are not rewritten, so one already stuck in that state stays there.
A capture that crosses New Year’s Eve is dated correctly. 2.7.0 fixed log timestamps taking the year the analysis ran instead of the year the log was recorded. One case it did not cover was a recording that crosses midnight on 31 December. The entries after midnight were dated a year early, so the file appeared to run backwards across the boundary, and a recording of a few minutes could be reported as spanning most of a year. Displayed timestamps, the reported time span and the timeline all read correctly now. This is computed when a file is analyzed, so upload an affected capture again to get the corrected dates.
Files are no longer held back for a capability nobody could grant. Only three kinds of log need a capability on your account: telecom, automotive and kernel crash dumps. When a log was confidently sorted into some other category, the file uploaded, counted against your storage, and then was never analyzed, with a message asking you to request a capability that does not exist and that no administrator could have enabled. Those files are analyzed normally now. Two related refusals are also gone: an ordinary log could be held back over the capitalisation of its category, and so could a customer who held exactly the capability their file needed. If you have a file that uploaded but was never analyzed, with a message naming a capability you did not recognise, upload it again.
Kernel dumps stop reporting a healthy machine as broken, and read far more of what is in them. Several things a dump analysis told you were wrong. Ordinary kernel threads parked and waiting for work were listed as stuck, dozens at a time, which buried the one genuinely hung task among them. The crashing task’s own backtrace was wrong on both processor families, coming back either empty or as several confident frames of something the machine was not doing. A subsystem a kernel was simply not built with was reported as something we had failed to read rather than as absent, which on an ordinary Linux server was most of them. Whole categories of evidence were reported as unreadable when the fault was ours, and roughly twice as much of a dump now comes back. Separately, a subsystem the dump never used could be attributed to it, and was then handed to the investigation as somewhere worth looking. Results are computed once and stored, so a dump you analyzed before this keeps its old readings: upload it again to get these. If you have a dump that ran without a debug image and you have since uploaded one, the existing re-run picks all of this up as well.
A multi-file upload no longer reports finished early, or never finishes at all. A bundle or archive worked out whether it was done by counting how many of its files were finished, and that count was wrong in both directions. A file whose charts were still being generated counted as finished, so the upload could report finished while its own pages still said they were being built. A file whose upload stalled and was timed out counted as unfinished forever, so anything polling that upload waited on a state that was never going to arrive. Both now ask the same question about a file being finished that the rest of the platform asks, so the upload reaches a terminal state and reaches it at the right moment. If you poll a multi-file upload, this is the case where a loop could previously hang indefinitely.
The average signal chart stops disappearing, and charts the cell you are registered on. The chart of average signal level over time vanished from the analysis entirely whenever a capture included readings taken while the modem was powering up. Those are reported as a placeholder rather than a measurement, and averaging the placeholder in put the result outside any real range, which removed the whole chart at exactly the moment a radio engineer is reading for. Readings are now bounded before they are averaged. Separately, on a line carrying readings for more than one cell, the chart could take a neighbouring cell’s value for a line labelled as the cell you are registered on. It now prefers the registered cell. Both apply to any log carrying the radio’s own reporting, which includes an ordinary bugreport and not only a dedicated telecom capture. Charts are built once and stored, so upload the file again to get the corrected chart.
An outage on our side really does answer a retryable error now. When we cannot classify an upload because something on our side is unavailable, the response is now 503 asking you to retry, rather than a 400 telling you the format is unsupported. Until now our own outage reached you as a confident verdict about your file, so a file that was perfectly fine came back with a permanent error you could do nothing about. If you have never seen a 503 from an upload, you may start to, and it means what it says: retry it, your file is fine. It is listed with the other upload status codes in Conventions.

2.7.0 (2026-08-14)

Breaking

Investigations answer 403 when the account is not entitled to that log’s vertical. Telecom, automotive and kernel-dump analysis need the matching capability on your account, and that is now checked at every investigation rather than only at upload. Quick search, deep research, comparisons and follow-ups on all of them can now return 403 where the call previously ran and was billed. Handle a 403 on /api/v1/files/{fileId}/searches/{quick,deep} and /api/v1/delta/{deltaId}/searches/{quick,deep}. If your capability was revoked, or a file was classified as a vertical after you queued it, this is what you will see.
Quick search answers 422 when the capture is why there is no answer. When a quick search cannot answer for a reason you can fix, such as no matching debug image on file for that build, the response is now 422 with a sentence saying what is missing. Failures on our side stay 5xx. Both used to be 500, so anything treating a 500 as retryable was retrying something no retry could fix.
Every rate-limit response is JSON in the standard envelope. Three of the rate limiters used to answer 429 with a bare plain-text line, and the two that returned JSON had drifted apart in wording. All of them now return the same JSON envelope every other error uses. If you parse a 429 body as text, parse it as JSON.

New

Qualcomm baseband captures upload directly. Both container forms upload as they come off the device, with no vendor tool and no text export first, and are recognized by their contents rather than their extension. You get signal level per cell over time, cells ranked by signal with the range observed, a control-plane sequence ladder naming each signalling message in order, the record-type and radio-technology mix, and a statement of how much of the capture was decoded. This needs the telecom capability on your account; without it the capture still uploads and stays searchable, but analysis is refused before anything is billed. See Telecom captures.
Linux kernel core dumps are a supported upload. Upload a vmcore from x86-64 or ARM64, plain or in the compressed form most distributions write. With no debug image at all you get the recovered kernel log, the kernel release and boot command line, the fault the kernel itself reported, and each CPU’s saved registers. The recovered kernel log becomes a file in its own right with its own dashboard and search. This needs the ramdump capability. A dump captured from outside the machine, by a hypervisor or cloud provider, carries less than one taken inside it, and on ARM64 that shape needs a debug image. See Kernel dumps.

Changed

Comparisons accept multi-file uploads and question binary captures directly. You can now compare bundles, archives and crash captures instead of being refused, and network captures, kernel dumps and baseband captures can be picked. A comparison also puts your question to each binary capture’s own records rather than reading only its earlier analysis. Two things follow that affect cost and limits: a comparison is created over the container’s members, not the container, so the 100-file limit applies to the expanded set, and because comparisons are metered per three files, comparing two large containers can draw more units than comparing two plain files. The per-operation weights themselves did not change.
Kernel symbols are matched to the exact build, not just the version. A debug image that matched only on kernel version was a coin flip, and it reported itself as a success. Symbols are now keyed to the build, and a version-only match that turns out to disagree is refused with a message saying so rather than used. Upload the debug image for the exact build. Separate distribution debug files, the vmlinux-<version> and .debug files from a -dbg or -debuginfo package, are now accepted as well; artifacts you have already uploaded still resolve.

Fixed

A file no longer reports completed before it has been analyzed. There was a short window between indexing finishing and analysis starting in which a file answered completed with nothing analyzed yet. A poll landing inside it took an unanalyzed file as finished. That state now reports analyzing, and a file that fails to reach analysis at all settles as failed rather than sitting at processing.
Kernel dump dashboards show their full chart set again. Dump dashboards were falling back to a minimal three-block view, so you saw findings but no device identity, no forensic charts and no recovered screenshot. Re-open a dump you looked at recently; the charts are there now.
Investigations you did not get are credited back. A queued investigation that is later declined now has its units credited back, into the same period the charge landed in. Previously it was charged when queued with no way to reverse it. A quick search whose retrieval found nothing to read, where no investigation actually ran, is no longer charged at all. The per-operation weights are unchanged.
A large binary capture inside an archive is no longer skipped. A multi-gigabyte network capture inside an uploaded archive hit a per-file size limit and was silently left out of the results. Large captures are now read as part of the archive’s overall budget. The protection against archives that expand to far more than they claim still applies to everything else.
Log timestamps use the year the log was recorded. Android’s default log format carries no year, and we were filling in the year the analysis ran. Any log captured in an earlier year showed wrong absolute dates on its timeline, in its recorded time span, and in any duration measured across files. The year now comes from the file’s own contents, the recording timezone is read from the file where it states one, and two files that cannot be reliably aligned are reported as such instead of being correlated anyway.
A failed PDF export says so instead of producing a blank report. When a report could not be loaded, the export still produced a valid one-page PDF reading “Report unavailable”, which is hard to tell from a genuinely short report once it is in someone else’s inbox. It now fails with an error, so you know to export it again.

2.6.0 (2026-08-13)

New

Upload a debug image later and re-run the analyses it unblocks. Uploading a vmlinux after a dump had already been analyzed used to change nothing, and the only way to get the deeper analysis was to upload the whole multi-gigabyte archive again. The reference library now tells you which of your earlier analyses the artifact unblocks and offers to re-run each one.
Kernel dumps yield much more without a debug image. A dump with no matching vmlinux now recovers the secure world’s event stream, each co-processor’s own record of why it stopped, per-driver event rings resolved to the driver that owns them, deferred kernel work that was actually in flight, and per-instance lock ownership. The dump dashboard goes from four charts to six without a debug image, and to nine with one.
Organization owners and admins get a usage dashboard. If you own or administer an organization, you can now see org totals and a per-member breakdown: investigation units, files, storage this period, how many quick, deep and comparison investigations each member ran, and when they were last active, against your per-member caps. There is also an activity feed covering the whole organization.

Changed

Organization admins can no longer change who the owner is. An org admin can no longer assign the owner role, change the owner’s role, or invite someone who already belongs to another organization. Each of those is now refused in the console. Transferring ownership is a support request.
A capture that was cut short is analyzed as far as it goes. A truncated network capture used to produce nothing at all. You now get the full statistics for everything that could be read, flagged so you know the capture is incomplete, and it stays searchable. Separately, a search over a capture we could not open now says so instead of reporting no results, which read as a finding about your device rather than a failure on ours.
Self-hosted installs no longer need AWS credentials. Where secrets come from is now a setting, and the customer install defaults to reading them from the cluster, so an air-gapped deployment does not have to hold live AWS keys. Embeddings can also be served from inside your own cluster instead of calling out. This fixes an air-gapped install that indexed nothing at all and returned empty search results without reporting an error. If your install relied on the old built-in AWS default, set the secret source explicitly.
A failed upload now reports failed instead of processing forever. A file whose upload or ingest failed used to stay at processing indefinitely, with the real error recorded where nothing read it. It now reports failed, with the error and whether it is worth retrying. If you poll for status, you will now receive a terminal failure where you previously polled forever, so make sure your client handles one.
An outage on our side answers 503, not a claim about your file. When we cannot classify an upload because something on our side is unavailable, the response is now 503 asking you to retry, rather than 400 telling you the format is unsupported. If your client treats every failed upload as permanent, retry on 503. The file is fine.

Fixed

Perfetto traces are recognized by their contents, not their filename. A trace that lost its extension, from a re-download, an export tool naming by timestamp, or an archive entry called trace, used to be refused as an unsupported binary format. It is now recognized from the file itself and analyzed normally.
Usage figures and reset dates agree with each other. Setting an access period on an organization used to make usage appear to reset for some members and not others, because opening the console could create a zeroed counter. Every view and every limit check now resolve the same period, and both surfaces state which period a figure covers. Reported usage may legitimately differ from before for accounts on a non-monthly period.

2.4.1 (2026-07-28)

Changed

The playground allowance is 5 investigation units a month. Playground accounts get 5 investigation units per month instead of 25. Storage is unchanged at 250 MB, and uploading and analyzing files still costs nothing. Paid accounts are unaffected. The welcome email now states the allowance the account actually has rather than a default.

2.4.0 (2026-07-27)

New

A public playground you can sign up for yourself. There is now a free public sandbox at playground.logcat.ai with open signup, no invite and no approval step. It is a shared public environment, not a private workspace, so upload only what you are comfortable sharing. The terms covering it are section 9 of the Terms of Service.

Fixed

Configuration files upload on their own. A hostapd.conf, an OpenWrt config, a firewall ruleset or any other key-value configuration file can now be uploaded by itself. The same file inside an archive already worked; sent alone it was refused as an unsupported type, including after a large one had finished transferring. It is now indexed and analyzed like anything else.

2.3.1 (2026-07-25)

Changed

An expired access period now blocks uploads too, not just investigations. If your account has a fixed access period and it has expired or not yet started, uploads are now refused as well as investigations. Both answer 429 with the reason and the date, so an integration that treats every 429 as a quota problem will report the wrong cause. Read the message. An active paid subscription overrides the period, and existing data stays readable either way.
An access period is now the quota period. When your account has a fixed access period, your investigation units are one pool covering that whole period, and they no longer reset on the first of the month. The usage view now names the period each figure covers, so you can see which pool you are drawing from. Accounts without an access period are unaffected.
The activity feed shows outcomes, not uploads. Upload lines no longer appear in your activity feed. The feed now carries the things you are waiting on, analysis ready and analysis failed, rather than restating an action you just took. Nothing you could subscribe to changed.
A webhook that answers 4xx is not retried. If your alert endpoint returns a 4xx, the delivery is dropped immediately instead of being retried on the backoff schedule. A 4xx means the request will not succeed however many times we send it, so retrying only delayed you finding out. Timeouts, 408, 429 and network failures are still retried. Check your endpoint after rotating a signing secret or moving a path: alerts sent during the gap are not redelivered.

2.3.0 (2026-07-21)

New

A single file’s dashboard opens with a written summary and a device card. A dashboard used to open straight into charts. It now leads with a paragraph reconciling the file’s findings into one read of what happened, above an identity card drawn from the file’s own evidence: model, build, kernel, timezone. Both were previously only on multi-file uploads. A file that says nothing about its device shows no card, since everything on it has to be evidenced by the file itself.
Dashboard tabs are linkable, and Back works. The tab, sub-tab and selected subsystem are now part of the URL, so you can bookmark or send someone a link to the exact view you are looking at. Back and Forward step through that navigation instead of dropping you out to the file list, and a finding’s evidence link now jumps to the whole cited range rather than its first line.

Fixed

.7z archives upload. Every .7z upload used to fail, whatever was inside it. Since a kernel ramdump normally ships as a .7z, that was the usual way of sending one. Both the extraction and the size check against your storage quota now work. Self-hosted installs get the same fix.

2.2.0 (2026-07-20)

Breaking: investigation steps in search results now carry a smaller, stable set of fields.

What changed. A step used to include internal working data from how the investigation ran. Those fields were never part of what a step means to you, and every one of them was something we had to keep unchanged forever. A step now reports what it examined and what it found: step_number, step_title, step_title_key, key_findings, citations, duration_ms, confidence, next_action, and the fields that describe the shape of the investigation when it splits into parallel threads and merges again (is_fork, is_synthesis, synthesis_kind, branch_id, branch_label, branch_status, parent_step_number, subset_label, is_planner_step).
What you need to change. If you read chunks_found, search_query, detailed_findings, reasoning, web_search_*, gerrit_*, external_*, library_search_*, source_discovery_result, fetch_url_*, inspected_*, next_step_title, confidence_note, effective_max_steps, unanswered_questions, dismissed_questions, or subset_files off a step, those fields are gone. The findings themselves are unchanged: key_findings and citations still carry what the step concluded and what it relied on. This applies to search results wherever they appear, including shared and printed reports.
Why. The answer is the product. How we arrived at it changes as the investigation improves, and publishing it made every internal adjustment a change to your integration.

2.1.0 (2026-07-15)

Breaking: the structured and unstructured file types are retired. Both are now log.

file_type is log for text logs. The two old values never described the file: they recorded whether logcat.ai could parse a log into columns. That is a property of what we managed to read, not of what you uploaded, so it now travels as its own field instead of masquerading as a type. Every remaining value names a real format or container: bugreport, logcat, dmesg, log, config, perfetto, pcap, ramdump, bundle.
What you need to change. If you filter GET /api/v1/files by file_type=structured or file_type=unstructured, use file_type=log. Those two values are now rejected with a 400 rather than silently returning nothing. If you send entity_type on a search or WebSocket frame, send log. Existing files were converted, so nothing needs re-uploading.
has_field_grammar tells you what the old split was trying to. Each file reports whether it was parsed into columns, so you can tell a column-filterable log from a plain-text one directly instead of inferring it from a type name.

2.0.0 (2026-07-12)

logcat.ai now analyzes binary captures and memory dumps as queryable data, and every analyzed file gets a dashboard.

Kernel ramdump analysis. Upload a Qualcomm dump archive and get post-mortem forensics on a device that crashed hard: reset reason, NoC bus faults, DCC hardware registers, running tasks and CPUs, loaded drivers. Upload a matching vmlinux to the new References library and the analysis also recovers the kernel log, the userspace logcat, and the on-screen framebuffer from memory. See Kernel ramdumps & References.
Network captures and Perfetto traces. .pcap / .pcapng, btsnoop Bluetooth HCI logs, SQLite snapshots, and Perfetto traces are decoded at upload and analyzed as structured data, so Quick Search and Deep Research query the records directly and can answer with exact counts, flows, and slices. See Network captures and Perfetto traces.
Multi-file bundles. Upload an archive of logs as-is. Each file is analyzed on its own and findings are correlated across the set, so an identifier that’s meaningless in one file can be resolved using another file in the same upload. See Multi-file bundles.
The analysis dashboard. Every analyzed file gets a dashboard built for what it is, with an event timeline and charts chosen for that format. See Analysis output & dashboards.
The public API and webhooks. Upload, poll, fetch a dashboard, and search over /api/v1, or subscribe to a webhook and skip polling. See the developer docs.
Every file is analyzed automatically. You don’t trigger analysis and it doesn’t cost you units. Only telecom, automotive, and kernel-dump logs need a matching capability on your account.
Usage is metered in investigation units. One budget covers search and research, priced by the size of the question. Uploading and analyzing a file costs nothing. See Investigation units & quotas.