Why Does My Raspberry Pi Randomly Reboot or Corrupt Its SD Card?

Detailed Explanation

Random reboots, unexplained freezes, and SD card filesystem corruption on a Raspberry Pi are three of the most commonly reported field symptoms — and in the large majority of cases, none of them are a software bug. They are downstream symptoms of the board's supply voltage sagging below its minimum operating threshold, usually under transient load rather than continuously, which is why the problem is often intermittent and hard to reproduce on the bench at idle.

This page covers how to confirm undervoltage as the root cause, the two most common physical sources of it, and how to fix each — as distinct from debugging a CM4 carrier board's own power supply design, which covers the same underlying voltage-sag failure mode from the PCB design side for a custom product rather than a stock Pi board.

Confirming Undervoltage With vcgencmd

Before investigating any specific cause, confirm undervoltage is actually occurring. Raspberry Pi OS includes a built-in undervoltage detection circuit and reporting tool:

vcgencmd get_throttled

This returns a hexadecimal bitmask. The bits that matter most for reboot/corruption troubleshooting:

A result of 0x0 means no power or thermal event has been detected since boot — if the fault reproduces while this reads clean, undervoltage is not the cause and the investigation should move to the SD card or OS instead (see the FAQ above). A non-zero result with bit 0 or bit 16 set confirms undervoltage is either happening now or has happened at least once — the practical starting point for the rest of this page.

The classic lightning bolt icon in the top-right corner of the desktop, or a Under-voltage detected! kernel log message (dmesg or journalctl -k), are the same underlying condition surfaced through the desktop UI and kernel log respectively — any of the three (icon, log message, or get_throttled bit) confirms the same root cause.

The Two Most Common Sources

1. Underrated or Marginal Power Supply

The Raspberry Pi's peak current draw under full CPU load plus attached peripherals (USB storage, HATs, displays) is substantially higher than its idle draw. A power supply rated for the board's idle or light-load current, or a generic phone charger not designed to hold its rated voltage under a sustained load, sags under real operating conditions even though it appeared adequate during a quick bench check. Raspberry Pi's own documentation specifies a minimum supply current rating for each board generation — always use the specific supply rating for the board in use (it increases with each generation, particularly the Pi 4 and Pi 5) rather than assuming a supply that worked for an earlier Pi model is adequate for a newer one.

2. USB-C Cable Resistance (Pi 4 and Pi 5)

This is a well-documented, Pi-4/Pi-5-specific issue distinct from PSU sizing: some USB-C cables — particularly cheaper or longer cables, and certain "e-marked" cables intended for high-power laptop charging that were not designed with thin, low-resistance conductors for this current range — have enough conductor resistance that the voltage drop across the cable alone, under the Pi's peak current draw, is enough to pull the board below its undervoltage threshold, even when the source supply itself is correctly rated and measures full voltage at its own output. This is why swapping only the power supply sometimes doesn't fix the symptom — the cable itself is the resistive element causing the drop.

Diagnosis Workflow

1. Confirm undervoltage with vcgencmd get_throttled as described above — don't proceed further based on assumption alone.
2. Reproduce under sustained full load, not idle. Run a CPU stress tool across all cores while any attached peripherals (USB storage, HAT, display) are active simultaneously — the fault is a transient load condition, and idle-only testing frequently fails to reproduce it.
3. Measure at the board's power input under that load, not at the source supply's own output terminals — the difference between the two measurements, if any, quantifies exactly how much the cable (or any connector/wiring in between) is contributing to the drop.
4. Isolate cable versus supply by substituting a short, known-good, thick-conductor USB-C cable (or, for boards with a barrel/GPIO power input, a short low-gauge wire directly to the source) while keeping the same supply, and separately substituting a supply rated well above the board's minimum current spec while keeping the same cable — whichever substitution resolves the undervoltage flag identifies the actual faulty element.
5. Check SD card health separately once undervoltage is ruled out or fixed — a clean get_throttled result during a reproduced fault points away from power and toward the SD card or OS instead (see the FAQ above).

Design Considerations

• Size the power supply and cable to the board's peak load, not idle — see the FAQ above for why a static multimeter reading at idle is not sufficient evidence that the power path is adequate.
• For a custom product built around a Compute Module rather than a stock Pi board, the same undervoltage failure mode applies to the carrier board's own power supply design — see CM4 carrier board power supply sizing for the PCB-level version of this problem, including decoupling and regulator sizing for peak current.
• Prefer a short, low-resistance cable over a long or thin one for any Pi 4/Pi 5 deployment where the power source can't be placed close to the board — cable-induced voltage drop scales with both length and conductor gauge.
• Treat repeated undervoltage-triggered reboots as a data-integrity risk, not just a nuisance — an ungraceful power interruption during a filesystem write is a leading cause of SD card corruption on any embedded Linux device, so fixing the power supply also protects storage integrity, not just uptime.
• Zeus Design's embedded engineering team diagnoses field power and reliability issues on deployed Raspberry Pi and Compute Module products as part of embedded Linux and firmware development support.

Common Mistakes

• Assuming a multimeter reading full voltage at idle rules out undervoltage — transient sag under load is the actual failure mode and an idle-only measurement misses it entirely (see the FAQ above).
• Replacing only the power supply without also checking the cable, missing a Pi-4/Pi-5-specific cable-resistance issue that persists even with a correctly rated new supply.
• Treating random reboots as a software or OS bug and spending debugging time there first, when vcgencmd get_throttled would have confirmed or ruled out the power-related root cause in seconds.
• Reusing a power supply rated for an earlier Raspberry Pi generation without checking the current-generation board's higher minimum current rating.
• Not checking get_throttled immediately after the fault, rather than sometime later — the "since boot" bits (16, 17, 18) persist until the next reboot, so checking any time before the next reboot still captures a historical undervoltage event, but checking after a subsequent reboot loses that history.