Changelog

Colleagues in your organization can still open these investigations. A comparison that includes such a trace follows the same rule.

A trace uploaded before this release is treated as decoded, because which signal database decoded it was not recorded then.

You approve the connection on a logcat.ai page and choose what it may do. Running deep research is ticked by default and draws investigation units at the console’s rate; untick it to connect read-only. Disconnect any app at any time from Connected apps in Settings. Enterprise owners and admins can see and disconnect their members’ connections. Setup steps are on Claude connector.

• Logs, kernel logs, system traces and memory images now list these, as bug reports already did. A system trace gives its Android release, API level and kernel; a log whose kernel buffer printed its boot banner gives that kernel.
• A value the capture states in its own lines is preferred over a bug report’s device section, and a value only read from the capture’s text is marked as such. A memory image no longer shows its kernel version as its build.
• Comparison reports show each capture’s device and build. Investigations of bug reports also take the boot events and notable signals found in the capture into account.
• Baseband captures and bug reports list the home network that issued the SIM and the network the device was registered on, by network code and carrier. The home network is read from the subscriber identity the capture states, never from the cell the device was on, so a roaming device reads correctly. A capture that states no network names none, and the investigation then names no carrier rather than guessing one. Investigations use them for carrier-specific failures.
• Logs and captures uploaded before the change are read again by a one-time repair; a system trace uploaded before it gains this when uploaded again. Reports written before the change are unchanged.

Each question can say what kind of answer it expects (a count, a time, a value or an identifier), and an answer of another kind is reported as not determined. Every question you asked is listed in the report, in the order you asked it, including the ones the files could not answer, wherever you read, share or print it.

The same asks list works on a single capture and on a comparison, over HTTP and over the streamed deep endpoints. See further questions.

A text log that opens with something other than log lines, such as notes or a page header, is accepted when the rest of the file reads as a log. A persistent kernel crash record whose first stored crash was erased is read from the crashes stored after it. See Supported file types.

• Each finding shows its kind of fault, and the findings the verdict rests on are marked. A proposed fix shows its upstream change and target.
• A “no fault found” answer shows the term searched for and where, and is given when the event you asked about is not recorded in a window your capture covers in full. Where the evidence stops also names facts that limit the answer, such as a time you asked about that the capture does not wholly cover.
• The location names every level the investigation concluded, and a process by its name and process number; when the cited line shows only the number, the name comes from elsewhere in the capture. A kernel cause names its subsystem and its function, a source file is named where a crash prints one, and a hardware fault’s component is the device its error lines name. When the cause rests on a stack trace, that stack’s class fills or narrows the component. Findings, chain steps and proposed fixes name a process the same way.
• A misconfiguration names the setting the fix changes, by its key and with a value only where the report states one, and the configuration file holding it where known; a SIM’s configuration is named by its elementary file.
• A level the capture does not print is marked as placed by the investigation, and each answer to your further questions says how its value is known.
• When code only printed the record the investigation read, it is named on its own Reported at line instead of as the cause, unless a test that settled the cause read a record that code wrote.
• Confidence reads medium at most when no test told the cause apart from the others weighed, or confirmed it, and low when a test’s result went against the cause; a cause a test decided keeps its confidence. The reason is shown beside it.
• Opening a quoted line in Logs goes to the exact line the report recorded; a source in an older report, or one whose line was not located, opens at the passage it was read from.
• Exported reports show the same levels, answers, reasons and lines in words.

In the API, the report gains verdict_outcome, verdict_mechanism, chain, absence_searches, verdict_reported_at (a list of location levels) and confidence_limit.reason (rivals_remain, unconfirmed, not_tested, contradicted, not_recorded when no finding states the verdict’s cause, or cause_disputed when the evidence also fits another cause; absent when nothing lowered the confidence). Location levels gain document, section and setting, and each carries provenance (printed or stated). The verdict location field holds the place the investigation concluded and is no longer left out when the verdict’s wording names it differently. Answers gain question and, when stated, basis (printed, computed or unverified); findings gain mechanism and supports_verdict; citations gain quoted_line; proposed fixes gain upstream and target. In the report contract, RCAfile 0.4.0, a cause may state reported_at; where it is absent, the document does not say. Reports written before this change show what they stored, so older ones carry none of this. See Reading the report and Further questions.

Before this change a signal database chosen at upload was passed over and the trace was matched against your library instead. Traces uploaded before this change gain both when uploaded again.

Signal definitions and decoded values are visible only to the organization that uploaded the signal database.

• Captures whose platform version we hold no source for are analyzed as before, without citations. See /guides/source-grounding/ for which platforms are covered.
• Kernel logs from a Pixel 9 device whose kernel version matches the source we hold are now cited to the line of that kernel’s source.
• When a capture’s own stack traces show the device runs a different build of a source file than the one read, citations of that file say so, and a suggested change to a function is offered only where the investigation read that whole function.
• On a self-hosted installation without source citations, each capture and Deep Research report now says they aren’t set up there, instead of showing nothing. Your administrator can set them up; nothing about your captures needs to change. A brief outage still reads as citations being unavailable at the time, which usually clears on its own.

Deleted source trees and reference files are never served this way. In EU deployments a download needs your organization’s approval, like any other staff read. See Staff access to your data and Retention.

Bugreports uploaded before this change keep these buffers inside the report itself, where text searches still find them.

The size limits are listed on Supported file types. A self-hosted install can change this limit.

• A cited web page was filed under Source Code as if it were your device’s source.
• A searched-for source citation now reads the same in the report and its step cards.

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 and empty files are not counted, so large captures with many rotated logs that the old 100-file limit refused now upload. A bugreport counts as each analysis it produces, whether it is a bugreport text file under any name or a .zip whose name starts with bugreport; a bugreport .zip under another name is opened like any other archive, so each file in it counts. A ramdump parser report counts once for itself and once for each log analyzed from it. Nested archives count toward both limits. An archive over either limit is refused with a message saying so, and nothing in it is analyzed. See /uploading/supported-file-types#size-limits.

GET /api/v1/files/{id}/source/missing-signals still answers, with empty signals and by_anchor lists and absences set to not_computed. The evidence read lists only lines that printed and carries the same absences value. Read that value rather than an empty list: it says nothing was computed, not that nothing is missing. See Reaching this from the API.

When an account is deleted through the product, its entries stay in the history but no longer name the person: its ID becomes a pseudonym, its email address and the network addresses it acted from are removed, and so are the names it gave to captures on the entries that record its own actions. An ID or address matches only where it stands alone, a free-text mention never makes an entry the account’s, details naming someone else stay, case is ignored for A to Z only, and a value shortened when recorded can keep part of one. Accounts deleted since 3 July 2026 are treated the same way where their deletion was recorded. A personal workspace is kept under a neutral name.

Billing records, retained copies of its captures, backups and logs until they expire, and notifications already sent can still refer to it; see Security and data handling.

A single uploaded file is priced exactly as before. Only the minimum price is checked before the archive is analyzed; the charge is made when analysis finishes and can be higher for a large archive. Files whose analysis did not complete do not count toward an archive’s minimum. A bugreport counts in full when its own analysis, or that of any log taken from it, has completed by the time the archive finishes, and a ramdump parser report counts the same way.

Over the API the file carries content_outcome: "too_large", and a deep research, quick search or follow-up request against it is answered with HTTP 422 and an error_code of content_too_large. See /developers/lifecycle-and-status and /uploading/supported-file-types#size-limits.

Source that can be read but not searched gets the single-pass fix at the single-pass rate. The steps a fix shows while it works now name the code it searched for and the files it read. Fixes already saved are unchanged and are not charged again. See Candidate fixes.

• Where it sits. A finding or verdict names only what its cited records print, spelled as the capture prints it, so a location may stop at the process. It is left out when a finding names no failing thing, or when the verdict states no cause, its cause was revised after the investigation, the verdict names a different place, or no location was established. It appears under the finding or verdict in the report, in the written answer, and in the API as a finding’s locus field and the verdict location field.
• Ranked causes. The verdict’s cause comes first, then the report’s other hypotheses ranked by the evidence for each, with ties marked and whether the tests left each standing or ruled it out. Each carries the kind of fault it names, where it sits and its citations. The verdict stays the report’s answer. In the API, the report’s candidates hold the ranking and each hypothesis names its candidate. Reports written before this release show their hypotheses as they always did.
• Computed figures. A figure the investigation computed from what it read, such as the time between two events or a count across table rows, is shown as computed: hover its source to see what was computed and from which sources. It is not checked against the capture the way a quoted figure is, so a claim resting on one is stated at medium confidence at most. In the API, such a source carries the preview kind computed.
• Web research. When an investigation, or the check of its report’s claims, searched the web, one Web research section says so and lists the pages it cites, each beside its number in the sources list. It replaces the line the report’s context carried when a search ran while a stated OS version was known, and says that too. In the API the report carries it as web_research.

See Deep Research.

• Older Android releases. On a capture from a device running Android 9 to 12, a cited log line links to the code that printed it, at that release. Before, a report on these releases said the source for the device’s release was not held.
• Upload your own source. Email sales@logcat.ai to have it enabled for your organization; owners and admins manage it. Upload a tar, tar.gz or zip archive of up to 32 GB; one holding a link, a device or a path outside the tree is refused. The tree is built on our platform and no other organization can see it. You hold one tree per kind and release; delete it to upload a replacement. Captures uploaded afterwards are cited against it. Investigations and fixes on captures in your organization, colleagues’ included, send relevant excerpts of it to our model provider. Enriching a tree, describing what each log statement means, also sends the code around each log statement, so it runs only after an owner or admin consents and not where your data residency forbids it; enrichment does not draw on your investigation units. See Upload your own source.
• Self-hosted deployments. Your administrator can build the source index from your own tree inside your environment, encrypted under a key that exists only there and is kept out of its backups, so no part of your source is sent anywhere to build it. A rebuild is swapped in without a restart, after it is checked against a reference capture you choose; one that would cite fewer of its lines is held back unless your administrator overrides it. Your captures are cited against your tree ahead of the published source at the same release, and no other organization is cited against it. A capture is matched to a tree when it is uploaded, so captures already analyzed keep their citations; upload one again to cite it against your tree. See Your own source.
• An OS version you state. When an Android or Linux kernel capture doesn’t state its OS version, its Overview and your capture list say so and list what was detected. Its owner can pick the version or type it, and new investigations cite source at a picked version we hold, as the device’s source; fixes may be proposed against it, labelled as matched on the stated version. Nothing is re-run or charged. An Android version we hold no source for is read at the nearest one we do, or from its public source, as a reference only; a Linux kernel version is matched exactly or not at all. A typed version, or one used in a comparison, is context only. The capture’s own OS version always wins: where the two differ, the report names both and relies on the capture’s. See An OS version you state.

• Staff access. A request covers the source behind your citations and the findings built on it. An approval lasts at most four hours. Every owner and admin is notified in the console when staff ask and when they first use an approval, and by email where your deployment sends email. Every read made under an approval is recorded, and requests, approvals, denials and revocations appear in your organization’s activity feed. An account outside an organization decides its own requests in Settings and sees them in its own activity feed. In EU deployments the same approval is needed before staff can read your organization’s data through the console or staff tools, not just source. See Security and data handling.
• Retention windows. Content you have not deleted is never removed on a schedule. A window can be anywhere from 7 days to 10 years. Until it passes, deleted uploads can be returned on request (their analysis is not, and deleted reference files are uploaded again instead); after it passes, nothing can be returned. Copies in our backups are removed as the backups rotate, within 32 days.
• Terminating an organization is a deliberate act by us, which can be reversed until removal begins 14 days later at the earliest. Removal ends every membership, revokes the organization’s API keys and destroys its content: uploads, analysis, investigations, reference files, settings and deleted content. Each member’s own account and personal workspace are kept. See Security.

The data allowance counts what was uploaded during the contract term, in decimal units (1 GB is 1,000,000,000 bytes), at its expanded size: a compressed file or archive counts as the data it holds. Deleting a capture does not give its data back, but data you got nothing from is given back: a file that could not be processed, a file that needs a capability your organization does not have, and the files an archive skipped.

An upload the remaining allowance cannot take in full is refused, and nothing is counted for it. Captures already uploaded stay readable.

The alerts cover both the investigation-unit allowance and the data allowance. Organization admins choose who receives them in the organization’s alert settings: see Teams and SSO.

• IMS SIP and eCall. Each SIP message is read with its method or status, headers and body, so you can follow call setup and registration. Open a SIP record in the Logs tab to see the message, every header in order and, for an emergency call, its minimum set of data: the vehicle identification number, position and recent positions, heading, vehicle type, number of occupants, incident time, and whether the call was automatic or a test.
• Newer modem firmware. Signal and throughput records it writes are now read, so their measurements reach your charts and answers. LTE mobility (registration) state, each bearer’s QoS class and the serving cell’s identity are read too, and you can ask about them; a record’s detail in the Logs tab shows them. LTE and 5G connection signalling is read and named, so setup, reconfiguration and release messages appear with the cell each was sent on.
• Firmware build. The analysis names the build the modem reported, from its own version answers and the collection tool’s status lines, how often it said so, and both builds when two appear. When the modem answered but its build could not be read, the analysis says so.
• Times. When a modem was never given calendar time, its records are placed on the device’s clock from the timed records around them, only when those keep one steady offset from the modem’s own count; otherwise a record keeps no time, and the Logs tab counts it and shows it with one click. The capture says when its modem ran on its own counter and how its records were placed, and how far the device’s clock sat from the capture PC, or from when the file was opened; small differences, such as a time zone, are not reported. A capture’s duration is its recording’s: a stray record stamped years away no longer stretches it.
• Message databases. Put a firmware message database in the archive beside your captures and it is added to your References before they are analyzed, so their compressed narration is restored on the first run. This needs the telecom log analysis capability; the database is never analyzed as a log, and one that could not be added is listed in the archive’s contents and your activity feed. When a capture names no database, its dashboard and analysis identify the one its narration needs by the end of its GUID, and say when the database on file is from another build. The right database now restores captures it was previously refused for, and records compressed against a second database are counted apart and left compressed.

See what you get from a Qualcomm capture and compressed narration.

• Hop by hop. Name the captures in path order and the connection’s two endpoints in your question. Address translation changes a connection’s endpoints, so a capture taken on the far side of it is compared as a different connection. A capture that was cut short gives figures that are minimums.
• Resent payload. A capture’s findings state what share of its TCP payload was sent more than once. The share is of the whole capture’s TCP payload, so one stalled connection among plenty of healthy traffic shows as a small share. Resends of data the receiver had already acknowledged are counted apart. Where a connection began before the capture did, the finding says so, because whether the receiver’s window held it back cannot be determined.

• CAN. Upload a trace again to have it read this way; traces uploaded earlier are not profiled.
• DLT. Control messages appear at their own CONTROL level, so you can filter for them, and a message sent without its text shows its message id. An ECU’s answer to a software-version request is recorded as that ECU’s version, read from the control message itself, never from a log line that happens to spell one.

Both syslog layouts are read with their timestamps and daemon names: the one with a facility and level on every line, whose level you can filter on, and the classic one with a host name. A layout without a year takes it from the capture.

The interface state chart reads OpenWrt’s interface lines. The Wi-Fi disconnect chart also appears on device logs that record Wi-Fi disconnects with a reason code, such as an Android logcat.

• Serial console. The PC’s timestamp is kept beside each line, and the analysis can state how far the device’s clock sits from the PC terminal’s. Upload such a capture as the terminal saved it: its own dashboard charts it as it would the log saved on the device. Syslog lines stamped with a full date keep their levels.
• Ramdump parser reports. Each kernel log, logcat or journal in the report gets its own findings and dashboard, and is read together with the report. The logs taken from a report are priced once, never again on top of the report. A section that holds only the ramdump parser’s own messages, with none of the device’s log lines, is not analyzed as its own log.

• Speed. On our benchmark of real device captures, a typical investigation went from about 25 minutes to about 15. A report says plainly when something could not be looked at, rather than treating it as absent.
• Before it concludes, an investigation may read error-level lines, protocols and tables in your captures it has not examined, and where the evidence stops the report says how many of each it did not examine. Its statements that something is absent, and its counts, are checked against the searches it ran.
• Times and counts. Where your capture states the date and zone, each time is a full timestamp, with your capture’s own form beside a converted one. A time recorded without a date is given as a time of day, and a time counted from boot or from the start of a recording is converted only where the same recording states what it counts from. Measured counts are stated as numbers, including zero.
• A cause the capture does not record. The report says the cause is not determinable from this capture and lists its leads, each with what would settle it. Reports of expected behavior say so plainly; when the investigation found that nothing failed, the report names no leading hypothesis, and a verdict that commits further than the capture could establish is shown at low confidence.
• A baseband capture still being prepared. The investigation opens by waiting for it, shown as its first step, for up to five minutes and across every capture in a comparison at once; the wait does not shorten the investigation. A capture still not ready by then ends the investigation before it starts, uncharged: try again in a few minutes. A capture that cannot be prepared at all does not hold the others back, and the report names it as not read.

• What the code does. The separate fires-when summary, which often restated the log message rather than the condition the code checks, is gone, and so is the suggested question built from it. A grounded finding recorded only with such a summary is no longer listed among the findings located in source. On the API, a cited line’s trigger field still answers this release and is deprecated: it goes in a later one. See Reaching this from the API.
• Reports. A report names the source it cites, such as Android 16 source, and cites the code the investigation actually read; a suggested code change is offered only where it read that code, and otherwise the report says the code needs reading first. If you read answers through the API, a citation now reads “Android 16 source: path:line” where it used to carry a bracketed source tag. Open those citations from the console.
• Vendor code. A citation into hardware or board code is checked against the release your device’s vendor partition states, which can be older than the platform’s. Where the source records that a file installs into the vendor partition and your vendor release differs, the line is shown for reference only and no new candidate fix is offered for it; a fix already worked out stays readable. A vendor release that isn’t a release of that source, such as a codename, is marked not comparable and treated the same way. Most source we hold doesn’t record that yet, so you’ll mostly see the softer likely vendor code mark, which withholds nothing. Where a capture states its exact build and the source was taken from a different build of the same release, the capture is marked different build. On the API, GET /api/v1/source/fix-proposal answers 422 with error_code partition_release_mismatch for such a line (partition_release_not_comparable for one marked not comparable), or 503 with partition_unread when the vendor release couldn’t be checked. See Marks on a citation.
• Step outward. Opening a citation shows the code, what it is recorded as doing, the whole file’s lines this capture printed, and a candidate fix. The list of the function’s other logging lines, callers and callees is gone; to trace a cause through the code, ask Deep Research, which reads the code it needs as it investigates.

Over the API the file carries content_outcome: "not_diagnostic", a new value beside empty, unreadable and none_analyzable, and an archive whose files are all empty now reports empty. A deep research, quick search or follow-up request against a file reporting empty, unreadable or not_diagnostic, or a comparison in which every file reports one, is answered with HTTP 422 and an error_code of content_empty, content_unreadable or content_not_diagnostic (content_nothing_to_compare for a comparison), instead of running. See /developers/lifecycle-and-status.

An installation with semantic search turned off answers 503 with error_code semantic_search_disabled and no Retry-After, since retrying will not change the answer. Keyword search keeps answering while semantic search is unavailable.

• When deep research cannot finish writing its report, you get the findings it established, each with its confidence and sources, instead of a failed investigation. The report says it has findings but no conclusion, and its reserved units are given back unless it stopped because it grew too long to finish; a report that grew too long after its verdict and direct answer were complete keeps them. Over the API it carries delivery: "findings_only".
• Deep research no longer fails, or stops at its findings, when the AI service behind it has a brief outage or a reply stalls: it retries while the investigation has time left. An outage that outlasts the investigation’s time still ends it, with the findings it established.
• A comparison of four or more captures that ran out of time while planning how to divide them now continues, keeps what it established, and marks what it did not reach as not examined rather than ruled out.
• Hovering a source that cites one log line the investigation looked up now shows that line and opens the Logs tab at it. Before, it said the capture had to be uploaded again, which changed nothing.
• Deep research, follow-ups and comparisons that query a Perfetto trace now reach every kernel event it recorded, including storage, filesystem and bus events, on traces you already uploaded too. A quick search reaches them only when a follow-up or comparison has just read the same trace, so ask about that activity through deep research; a compressed or very large trace, or one opened while several others are open, is read the previous way.

• Kernel logs that print a thread or CPU tag after each timestamp, as Android and many vendor kernels do, now get their crashes, panics and warnings listed with the call chain, and a hardware watchdog reset is reported as a critical finding. This applies to kernel logs analyzed from this release on.
• Baseband captures from telematics units and other modems that the earlier reader placed wrongly are now read record by record from the start, so their measurements, signalling and debug text reach your dashboard and answers. Records the capture tool sealed are counted under their type and time. A capture whose records do not match the layout we read is refused as unreadable, with the reason, and a record count that is a minimum says so.
• A very large baseband capture exported as QCAT or QXDM text, with long measurement tables, could stall while being indexed and never become ready. It now finishes; upload a stalled capture again. Binary modem captures were not affected.
• A packet capture uploaded beside a bug report no longer reads as a second device: the recording computer and program are shown as the capture machine, and the card says when the capture’s header could not be read. System traces show the Android release, API level, kernel and the recording session’s real length, or say when the trace states none. Robot recordings show their middleware family and release separately, and a CAN database file keeps its own revision. System traces uploaded before this show only the device details that were read correctly.
• Packet captures taken on IPv6 networks or on a modem or tunnel interface now list the hosts they saw, connection-health rows name both ends, and the overview names the real top protocol.
• A Perfetto trace’s memory, CPU and power summaries now read reclaim stalls, out-of-memory priority changes, resident memory, the busiest threads and every thermal zone it recorded, and say plainly when a trace did not record one. Traces analyzed before this keep their earlier summary. Deep research can also read the trace engine’s ready-made tables for app launches, binder calls and memory intervals.
• A signal your DBC file places on one page of a multiplexed message is now decoded only on frames that carry that page, and DBC files are matched against traffic sampled across the whole trace, including Vector ASCII exports written in decimal.
• CAN FD frames now keep their payload and flags, and remote requests and error frames are stored as what they are, in candump, Vector ASCII and Vector binary traces. A trace format that cannot record error frames is said to be one, rather than read as a bus without errors.
• A bugreport uploaded compressed, or saved as UTF-16 text, now shows readable log lines in the Logs tab.

• A file larger than the per-file size limit stops uploading at once with a message naming the limit, instead of ending in a network error. An upload that fails partway shows the server’s reason when it gives one, and the status otherwise.
• When a pattern search in the log viewer finds no lines, its counts, level chips, pickers and density strip show zero only once that is confirmed; otherwise they say none was found by the pattern but the result is not confirmed. See Log viewer.

On the API:

• A completed deep research or comparison returns report beside final_answer, on the session detail endpoints and on a shared report link: the verdict, key figures, ranked findings with severity, confidence and the citations they rest on, next steps, proposed fixes and sources, as typed fields. final_answer is unchanged.
• triage_data stays in the responses, so an integration that reads it keeps parsing. Investigations completed before this release keep theirs, and have no report.
• The fact_check citation type is retired. A citation is log_search, source_code or web_search.
• An investigation step’s next_action can be read_span, and a step another step asked for carries follows_step_number.
• A bugreport dashboard’s severity cells are keyed critical, warning and info.
• An investigation can run for about 40 minutes rather than 30. If you poll for results, allow for that.

Preparing a large capture can take several minutes and runs in the background once it starts, so the same question asked after Retry-After is answered from the prepared capture. A comparison quick search that could read none of its files for this reason answers the same way. A deep research that found its captures still being prepared and read nothing else completes and is given its units back. The console shows how long it expects the preparation to take.

There is no longer a per-plan choice of pricing: one rate applies to every account. The automatic analysis of an upload draws units too, and an archive or bugreport is charged once, not once per file inside it. A proposed fix still costs a flat amount per proposal. Your billing page shows what each operation drew.

Owners and admins see the allowance on the organization overview: what has been used against its size, what remains, the term’s dates and days left, and usage against the time elapsed, so spending ahead of the calendar is easy to spot. The member list marks anyone who has reached their own cap. Organizations without a shared allowance are unaffected.

The follow-up box shows the cost before you ask. A follow-up puts itself to each network, trace, dump or baseband capture it covers, up to four, and one that does is charged as a quick search over those files; a capture it did not reach is named in the answer as not read. A follow-up that ends without an answer is not charged.

From the code panel, step outward: the other lines in that function that log, and how often each fired in this capture; what calls it and what it calls; the whole source file with every line it prints, which ones your capture carried, and which it never did. A capture’s Overview also lists the lines the source says should have appeared alongside your findings and did not, which is often where the answer is.

A file with no citations says why at the top of its Overview, with what you can do about it. The References page lists the platform source we hold, which of your uploads were matched to it, and lets you search that source for a symbol, a log string or a file name.

Three marks tell you when to double-check a line number: the file comes from a modified build, the source we hold has been refreshed since the file was analyzed, or the code itself changed. A report you share by link says, frozen at the moment you shared it, whether the source behind its citations had moved since.

The code behind a citation, everything one source file said about a capture, what the source expected and never appeared, which source we hold and how each of your captures matched it are all on the API as reads taking the parameters a citation carries. Stepping outward from a line and the References search are Console only. Files also gain source and finding_counts fields.

See Source-grounded findings.

Watch it work: the dialog shows each file read and each call followed as the fix is worked out. If your connection drops, the work carries on and is saved. An attempt that stops before producing a proposal says why and offers to try again; one that stopped at a limit says which limit. An attempt that ran is charged, and asking again is charged again. A saved fix records the source build it was written against and offers a fresh one if that source has since been rebuilt.

Console only: asking for a new fix spends units, so it is not offered over the API. Reading an existing one is. A citation that names a likely line rather than the exact one shows the code but offers no fix.

See Candidate fixes.

The verdict card carries the question, a confidence pill and the direct answer. Confidence now follows the evidence: a finding whose citations point to nothing the investigation read is marked low confidence, so treat it as a lead to verify. Hover a source in the rail to read the passage it was taken from. A comparison names its captures on the verdict card and pairs their key figures.

A corrected claim is now simply stated correctly, without a list repeating each wrong version, in existing reports too. Quoted log lines read as code. Investigations completed before this release keep their previous layout.

An investigation whose captures are all in one space is visible to that space, with its own Investigations tab. One that mixes a shared capture with a private one stays private. Follow-ups a colleague asks are charged to them. Investigations run before a capture was shared are not shown; run them again.

Filter your file list to your own files, files shared with you, or one space. Over the API the file list returns your own files (scope=shared returns none), and space_id narrows it to those you published into a space. Each space shows its activity, its members and its spend for the period.

Organization owners and admins can open any space; the space is told when they do. They also get a Spend tab (units by member, by billing period) and a list of what the organization is entitled to analyze.

Organizations using SSO can turn on “Add people automatically”: anyone signing in through your identity provider from a domain you have verified joins as a member without an invitation. Off until you enable it.

On a shared capture, source citations are decided by the reader’s own entitlement, not the uploader’s. Captures a colleague shared into a space stay there when they move organizations, and comparisons over a departing colleague’s captures are recorded, refunded and stopped.

The density strip shows where lines cluster and flags spikes: click to jump, or drag to narrow to a range. Open any line for its fields, the insights that cite it, and the lines around it. A bundle’s Logs tab can show two of its text files side by side on the capture’s clock, moving together, and opens on the file tree when no text file could be placed on that clock. Links saved before, including citations in older reports, still open on the same lines. See the log viewer guide.

The Overview lists every finding the capture holds, not the first twelve, each once, under the subsystem that reported it; each subsystem tab lists every finding for its area, ranked the same way. Findings that describe one incident are grouped under a plain sentence saying what happened and how sure we are (By situation); findings from different areas that name the same package, process or symbol are grouped across areas.

Every measured reading names the section and line it was read from. Readings that were bare counts (“232 SELinux violations”) now list their rows. Storage shows each partition with size, used and full percentage. The header states the time span the logs actually cover. A recurring fault shows a timeline of when it fired. Kernel low-memory kills and SELinux denials sit on the same timeline as the rest of the capture, with the two clocks reconciled.

System services, Kernel and Boot, and Security gain charts. Logs extracted from a bugreport inherit its date and timezone. A bugreport uploaded as a single text file is split into the same sections as the zip, and when one section is too large to read in full, the sections after it are no longer skipped.

A bugreport already in your library shows the per-area tabs, the new charts and the partition table as it is. The crash dumps, thread dumps and previous boot inside the archive, and the full read of a text bugreport, come with a fresh upload; the situation grouping and the source line on each reading arrive when it is next analyzed.

Uploading a kernel debug image needs the kernel crash dump analysis capability on your account; a loadable module needs nothing extra.

Add any reference file (a kernel debug image, kernel module, CAN database, message database or firmware image) from one dialog on the References page, where everything you have given us is listed in one table. After you add one, the captures analyzed before it arrived are listed so you can re-run them deeper.

Your References library has a storage limit per organization. When it is full, a further upload is refused until you remove an artifact you no longer need.

• A Logs tab: the capture’s decoded records on one timeline, filtered by kind, technology, layer, direction, message type, firmware function and read state, with a density strip to zoom into a time range. Open any record for what was decoded, its raw bytes and the nearest records like it. It needs telecom log analysis on your account.
• Finding times are links that open the Logs tab at that moment.
• More radio readings for LTE and 5G: uplink transmit power and power limiting, reported channel quality and rank, and block error and retransmission figures. Times are in UTC to the millisecond.
• A chart with no records says why: not in the capture, not readable yet, or only partly checked.

A database is used only for a capture that names it or whose messages match it, so one from another firmware build is not applied. The analysis says how many records were restored and how many stayed compressed. A capture whose narration was already restored when it was collected no longer asks for one.

Trace messages render as text wherever the capture carries it. Add your firmware image (.elf) for the same build and messages the vendor withholds are attributed to the function that emitted them; the image itself is not kept. Both need telecom log analysis on your account.

• Robot recordings: ROS 1 bags, MCAP and ROS 2 database recordings upload directly, with the channel inventory, the time window and the robot’s own logs pulled out. Requires robotics analysis on your account; see Robot recordings.
• Vehicle bus traces: Vector binary (.blf), Vector ASCII (.asc) and DTS diagnostic (.trc) traces upload as recorded, no export step, and every trace format now finds your registered signal database on its own; a trace that came back with numbers where you expected signal names decodes when you upload it again. Two unrelated tools write .trc: open yours and look at the first line. [Description] means upload it as it is; a line starting with a semicolon means export it to text first.
• Wi-Fi captures get a radio layer: the association sequence, retries, deauthentications and signal strength. Packet captures also gain transport-health, ARP and industrial fieldbus analyses, and gzip-compressed and nanosecond-resolution captures upload as they are.
• Flash-partition (mtdoops) and pstore/ramoops crash records upload and decode as kernel crashes.
• Multi-section files (command-output dumps, support snapshots) get a section index on the dashboard.

See Supported file types.

• A bundle summary links the same crash across two of its captures, such as a lab run and its bench reproduction, by the code location both report. Bugreports line up in time with the bundle’s other captures.
• Network captures count the error statuses their file-sharing servers returned and the destination-unreachable messages they carry.
• A trace large enough to hold more gets an extra area of findings for what the standard areas did not cover.
• Captures, traces and baseband files open with a written summary, as logs already did.
• Captures that arrived inside an archive can be picked for a comparison.
• Ask a finished investigation again over more captures, with its question and selection pre-filled. It runs as a new comparison and is priced as one.
• A finding offers ready-made follow-up questions carrying its function, trigger and capture.
• The comparison picker shows what the first investigation will cost, and warns when an archive expands to more files than you picked.
• The question box accepts twice as much text and says so when a question is too long.
• After a release, the console shows you what’s new, once. Turn it off in Settings, where the notes stay available.
• A refused upload says what would make the file readable, and the list of supported formats is current.

Needs you lists your own captures where source matching is waiting on something only you can supply, such as a capture that does not say which build it came from, or a release we do not yet hold. The Needs you, Cites code and No source matched filters need source citations on your account. An archive’s headline is its worst finding across everything inside it.

Over the API, GET /api/v1/files accepts a state filter with the same four values and returns question_count on each capture.

A sign-in unused for a day still ends as before. Resetting your password, or an administrator blocking the account, also ends every sign-in. A sign-in you already have when this release is installed lasts at most 30 days from the release.

• Removing someone from your organization now removes their access to its entitlements and plan, not only their admin role. Members removed before this release are not corrected automatically; contact support.
• Someone joining your organization through SSO now leaves their old organization completely. An owner of another organization must transfer ownership first. Memberships split before this release are not corrected automatically; contact support if someone appears on your member list who should not.
• Stopping an investigation, or deleting the file it was reading, records as stopped instead of raising an “Investigation failed” alert. A run stopped before it started ends and refunds immediately, and reports as cancelled over the API with no intermediate state to poll for.
• Follow-up questions and quick comparisons no longer send a completion email each.
• An upload refused for a reason other than storage now says the real reason instead of asking for a smaller file. A file needing a capability you do not have reads as not included, not “Processing”.

• A deep research that gathered more evidence in one step than could be read at once now finishes and writes its report from what it had found, instead of failing.
• A quick search on a bundle puts your question to each network, trace or baseband capture in it, up to four, alongside the logs. A capture it could not read is named rather than reported as showing nothing.
• Deep research on a bundle is written up as one capture, not as a comparison between devices.
• A bundle in which one file failed to upload completes from the files that arrived.
• Where an installation could not reach web search, those steps now say the search did not run, instead of listing references that were never read.
• Taking a bug report is a minute of activity on the device; investigations now tell that collection apart from the device’s own behaviour.

• A device’s health score no longer rises when an area’s analysis fails; the area shows as not measured. Captures you already have may show a lower score or more “not measured” areas.
• CPU thermal state and storage low-space warnings come from the figures the device reported, not from word matches. Both could previously report Critical on a healthy device. Re-analyze a capture to get the corrected reading.
• System services running, sleeping and zombie counts are labelled threads, which is what they always counted.
• A quick question about a comparison of packet captures or dumps gets an answer instead of coming back blank, and a comparison that investigated nothing is not charged.
• A comparison you stop reads as cancelled, not failed.
• Kernel logs with a few stray bytes quoted from device properties, and baseband captures with a vendor header, no longer get refused as binary. Upload one that was refused again.
• Noisiest-tag and errors-per-minute charts appear on devices that label every log line. Re-analyze to draw them.
• The event timeline shows each boot in a multi-boot kernel log in turn, with reboots marked.
• Dashboard chart titles and table headings are translated in Korean and Chinese.
• Searching your files, investigations and activity treats % and _ literally.
• A file you uploaded whose name matched our extracted-log pattern is no longer hidden from your file list.
• A bugreport’s Critical, Warning and Info counts, and each subsystem’s issue count, count the findings the dashboard lists, so the totals always match. A battery that never reported its cycle count or health shows them as not measured, not zero.
• A network capture’s protocol-flag counts match its summary, periodic flows count every packet, and each chart says what it counts.
• A trace’s smoothness section finds frames that rendered quickly but finished late, counts frames rather than layers, and rates severity on the share of frames that hitched.

• A cited line has the line number your editor shows, even in files with blank lines. Logs stamped like “Wed May 13 22:54:19 2026”, or opening each line with a date-time and a level word, get a time axis, time jump and level filters. Logs already uploaded keep their earlier view until uploaded again.
• When a device logged before its clock was set, the event timeline covers only the log’s measured window and says how many events it left out.
• Wireless captures state which frames failed their checksum, traces state their real duration and where data was lost, and kernel crash logs state which crashes came from separate boots.
• On some modem firmware, a completed 5G reconfiguration was read as the network rejecting the device. It is no longer mislabelled, and a rejection is reported by the side that sent it.
• A fallback from LTE to a circuit-switched network appears as its own finding, with its times.
• Capture summaries no longer show stray asterisks, hash marks or list markers.

This covers a network capture, trace, kernel dump or baseband capture that something on our side stopped from ever being queued for analysis. 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.

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.

That covers a saved web page kept for reading, a plain-text contract, a data export that is a table of business figures, and source code. 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.

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.

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.

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.

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.

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.

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.

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.

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.

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 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.

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.

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.

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.

Both used to be 500, so anything treating a 500 as retryable was retrying something no retry could fix.

If you parse a 429 body as text, parse it as JSON.

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.

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.

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.

Symbols are now keyed to the build, and a version-only match whose build turns out to differ 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.

That state now reports analyzing, and a file that fails to reach analysis at all settles as failed rather than sitting at processing.

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.

The protection against archives that expand to far more than they claim still applies to everything else.

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.

It now fails with an error, so you know to export it again.

The reference library now tells you which of your earlier analyses the artifact unblocks and offers to re-run each one.

The dump dashboard goes from four charts to six without a debug image, and to nine with one.

There is also an activity feed covering the whole organization.

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.

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.

If you poll for status, you will now receive a terminal failure where you previously polled forever, so make sure your client handles one.

It is not a claim about your file. If your client treats every failed upload as permanent, retry on 503. The file is fine.

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.

The terms covering it are section 9 of the Terms of Service.

It is now indexed and analyzed like anything else.

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.

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.

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.

A file that says nothing about its device shows no card, since everything on it has to be evidenced by the file itself.

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.

Self-hosted installs get the same fix.