iOS Watch

A JetsamEvent Is Not a Panic: How to Ask for the Right File

By Alex Rodriguez, repair technician · October 8, 2026 · 4 min read · Leer en español

The customer swears they sent the crash log. They sent a memory report instead. How to tell JetsamEvent and panic-full apart in ten seconds, and why the difference decides the diagnosis.

It happens every month. A customer or another shop sends a file, says this is the crash, and the file is a JetsamEvent. It is a real Analytics log, it does describe the system killing something, and it is not a panic-full. Working from it as if it were a panic log leads to a confident conversation about the wrong event: the analyzer finds no panic string because there is none to find, no missing sensor because the file never tracked one, and the restart the customer actually cares about may not be in the file at all.

The quickest check is the name. In Settings > Privacy & Security > Analytics > Analytics Data, the files are listed by type and date. A kernel panic report carries the panic-full name; a JetsamEvent carries its own, just as other Analytics entries carry theirs — app crashes, resets, and system reports all sit in the same list side by side. They are neighbors, not synonyms. Before reading a single line, confirm the file name matches the kind of event you are diagnosing.

The deeper difference is what each file is about. A JetsamEvent is a memory-pressure report: the system ran short on memory, ranked processes by their use, and terminated one or more to recover. Apps being closed under memory pressure is a normal mechanism doing its job, even when it annoys the user, and the report exists to account for memory, not to announce that the kernel failed. A panic-full is the opposite kind of event: the kernel itself hit a condition it could not continue past, and the whole system went down. Memory accounting and kernel failure can both end with an app disappearing or a phone restarting in the customer's description, which is exactly why the files get confused — and why they must not be.

That is why the analyzer needs the panic-full original when the complaint is restarts or a suspected hardware fault. The diagnostic evidence this journal is built on — the panic string, the header, a missing sensor line, a watchdog naming what stopped checking in — lives in the panic report. A JetsamEvent contains none of it. Feeding it to a panic workflow does not produce a weaker diagnosis; it produces no diagnosis wearing the clothes of one, and any part quoted off it is a guess with paperwork.

So build the ask into your intake. When a customer says the phone restarts, walk them to the Analytics list and have them look for the panic-full entry dated closest to a restart they remember, and send that file complete. If there is no panic-full file near the incident, that absence is itself useful information — it may mean the event was not a kernel panic, and the diagnosis should start somewhere else entirely. The right file does not guarantee an answer. The wrong file guarantees you are answering a question nobody asked.

Filed under: JetsamEvent · Analytics · panic-full · intake

Check your own log

Have a panic-full .ips file from a phone doing the same thing? Run it through the free analyzer — it reads the file locally in your browser and shows you the evidence it finds, the inspection targets it ranks, and the next checks it recommends.

Open the free analyzer

Check your own log

More from the Journal