Drop the log.
Read the verdict.

What it reads

Detected from the contents, not the file name, and scored across every parser so a Linux log is never claimed by a Windows one.

• CBS.log, at %windir%\Logs\CBS\CBS.log. The servicing log. This is where Windows Update and DISM failures leave their real reason.
• dism.log, at %windir%\Logs\DISM\dism.log. Same line format, different component names.
• MSI verbose logs, the ones you get from msiexec /i package.msi /l*v install.log. It finds the action that returned 3 and the final exit code.
• Configuration Manager logs, both the CMTrace format and the older $$<component> one. That is one parser for roughly fifty files: smsts.log, AppEnforce.log, execmgr.log, UpdatesDeployment.log, CcmExec.log and the rest.
• syslog and journald. RFC 3164, RFC 5424, the rsyslog ISO format, and journalctl output including -o json. The tag becomes the component, so you get a per daemon breakdown.
• dmesg, both the plain monotonic form and dmesg -T -L -x, which is the one that actually carries levels.
• nginx and Apache, access and error logs. On an access log the status code is the level, because that is the server's own classification, and it doubles as the component so filtering to every 502 takes one click.
• Windows Event Log exports as CSV, from Get-WinEvent | Export-Csv or Event Viewer. Quoted fields that span lines are handled, which Event Log Messages routinely do.
• Anything else. If nothing matches, it still reads the file: timestamps, declared levels, grouped findings, context, and codes. An unusual log is the reason you came here, so being told "unrecognised" would be the least useful answer available.

What it does with a file it cannot parse

A .evtx, an .etl, or a zipped log bundle is not text, and no amount of parsing will change that. Rather than refusing it, the tool recognises the file from its first bytes and hands back the one command that turns it into something readable. Dropping an .evtx gets you the Get-WinEvent … | Export-Csv line, which you can then drop straight back in.

Why the context matters more than the code

In a CBS log the error line tells you the code and almost never tells you the object. The lines immediately above it name the file, the registry key, or the component that was actually refused. That correlation is the whole job, and it is why every finding here opens to show the surrounding lines rather than making you scroll to a line number in a text editor.

Why nothing is uploaded

Production logs carry device names, user names, and internal paths. In healthcare, finance, government, and defence, pasting one into a hosted AI tool is not a preference, it is a policy violation. So this tool does not have a server to send anything to. The file is read with the browser's own File API, parsed in a Web Worker, and never touches the network.

The counter above the fold makes that checkable rather than something you have to take on faith: it counts every network request your browser makes from the moment you hand over a file. It should stay at zero. Open DevTools and confirm it, or turn off your network entirely and watch the tool keep working.

What it will not do

• It does not tell you a log is healthy just because it found no errors. It tells you no failure was recorded, which is a different claim. Most syslog lines and all plain dmesg output carry no severity at all, so on those a count of zero means the lines did not declare one, and the tool says so rather than letting you read it as good news.
• It does not invent levels. A line is an error when it says it is, not because it contains the word "failed". Reading Failed password for root as an Error would flag every auth log on earth as broken.
• It does not parse the modern WindowsUpdate.log, because there is no text file to give it. That log is ETL based, and you have to run Get-WindowsUpdateLog in PowerShell to produce a readable file first.
• It does not read .evtx directly. Binary Event Log parsing in a browser is a large piece of work for a problem one PowerShell line already solves, so it hands you the line instead.
• It does not guess at codes it has not verified. Unknown codes get their structure broken down honestly instead of a confident invention, and a POSIX errno is never run through the Windows decoder just because both are called error codes.
• It is not a SIEM. It reads one file at a time, in one tab, with no history and no correlation across machines. That is the trade for having no server, and the trade is the point.