Bench Techniques · Multiple models
Every Three Minutes, On the Clock: What a Timed Restart Is Telling You
By Alex Rodriguez, repair technician · October 12, 2026 · 5 min read · Leer en español
Customers call it random. On the bench it restarts almost to the second. That interval is not a coincidence — it is diagnostic evidence, and it points to a sensor that stopped reporting.
Ask the customer and the restarts are random. Put the phone on the bench, start a timer, and a different story shows up: it restarts, runs for roughly three minutes, and restarts again, close enough to the same interval that you can set your watch by it. That regularity is the first thing to verify, before you open the phone and before you read a single log. Time two or three cycles yourself.
The pattern fits how the phone supervises itself. A watchdog expects regular check-ins, and the sensor system is polled on a schedule so the platform knows its sensors are alive and reporting. If a sensor never answers those check-ins, the watchdog does not wait forever. After repeated missed reports it treats the system as hung and forces a restart. The phone boots, the polling starts again, the same sensor stays silent, and the cycle repeats at roughly the same interval. In other words, the restart interval itself is evidence: a timed restart usually means something expected is missing, not that something random is crashing.
Start by confirming the interval and reading the log together. In Settings > Privacy & Security > Analytics > Analytics Data, open the panic-full file that matches the time of a restart you witnessed, and look for a missing sensor line. Earlier case files in this journal cover what a named sensor gives you — prs0 and mic1 point toward the charging flex, prox/als toward the front sensor flex — but even when the log is less specific, the steady interval still narrows the fault to the sensor-reporting path. Write the interval down on the ticket.
Then isolate, one variable at a time. With the phone open, test with suspect flexes disconnected and reconnected in turn, and where a flex is suspected, substitute a known-good one rather than simply reseating the original and hoping. Watch what happens to the pattern after each single change: does the timed restart stop, does the interval change, or does nothing move at all? Each result rules something in or out. Change two things at once and you learn nothing, because when the phone improves you will not know which change did it — and when it does not, you will not know which suspect to clear.
Do not guess parts off the timer alone. The three-minute pattern tells you the class of fault — a sensor is not reporting and the watchdog is doing its job — but it does not name the part. Ordering a flex because the interval sounds familiar is how good parts end up in good phones and the customer comes back with the same restart. Confirm the interval, read which sensor line is missing where the log offers one, isolate with known-good parts one step at a time, and let each test narrow the list. The clock got you to the right neighborhood. Only method gets you to the right part.
Filed under: watchdog · three-minute restart · missing sensor · diagnosis
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.
More from the Journal
- Reading the AOP: What "probe=0" and "no pulse" Actually Tell You
Bench Techniques · September 14, 2026 - Read the Header First: The First 30 Lines of a Panic Log Do the Heavy Lifting
Bench Techniques · October 19, 2026 - When the Log Says Nothing: The Insufficient-Evidence Workflow
Bench Techniques · September 30, 2026