Complication update rate is bounded by battery

What it is

Every time a complication rewrites the number on the face, the processor wakes, and it may hit the network or ask the phone. Charge is spent per rewrite. The face is present on almost every raise, so refresh rate is pinned by a battery budget: weather moving from “every minute” to “every fifteen,” rings jumping in steps instead of live, is not laziness. This small cell cannot feed a face that is always painting. This entry is only about the refresh cadence of slot content. It is not about always-on policy for the whole device, and not about how chatty the whole background-sync pipe should be—those are a different layer of the battery ledger.

Why it happens

The face is resident foreground. One slot update looks cheap; multiplied by hundreds of raises a day and by the system’s pre-refresh to “look alive,” it becomes radio-like idle drain. The system therefore hands each slot a timeline budget: moments when a value may change; past that, updates queue or drop. Apps that push with phone-side real-time habits (ticks every second, buses every ten) exhaust the budget; later updates are dropped silently, and the number on the slot is wrong with no mark. What people see is “the face lied,” not “the budget ran out.” Refresh also only matters if it lands before a raise: correcting a number while nobody is looking contributes nothing to this glance and still spends charge. Effective refresh is getting the slot that will be asked right before the next raise, not keeping every slot as fresh as possible.

Where it stops holding

Safety-related slots (a navigation turn, a heart-rate alert) cost more delayed than they cost in charge; they may briefly break the budget, and must give it back when the activity ends. Offline, or with the phone elsewhere, the pipe is cut; the slot should read as “not now,” not keep showing a stale value that looks fresh. Decorative second hands and animated faces also “update” and can eat the same budget as slots. That is face-rendering cost and should be booked separately; do not blame complications for all of it. A user who chooses “always show seconds” is explicitly trading battery for motion; slot refresh should not quietly follow that same frequency.

Applying it

• Set each slot’s refresh to how fast the question actually changes: clocks tick, buses follow an arrival window, weather follows the hour, calendar follows event boundaries. Do not put every slot on a shared “as live as possible.”
• Schedule updates before expected raises: buses before the morning peak, the next meeting before it starts—not a uniform sprinkle.
• When the budget is exhausted or the pipe is down, make the slot look old (fade, drop minute precision). Do not keep showing the last success as if it were current.
• Verify by logging each slot’s actual refresh interval and failures against the battery curve for the same hours. Drop a slot from “every minute” to an interval that matches the question; if “the face lied” complaints fall and all-day battery rises, the old cadence was spending refresh to fake freshness, not serving glances.

Related

• Within the group: K4.06.1 The watch face is the highest-frequency information entry · K4.06.2 Complications are tiny, so readability is tightly limited
• Adjacent: K4.08 Battery Constraints on Interaction Frequency · K4.08.2 Background sync frequency trades freshness against battery · K1.06 Widgets and Lock-screen Entry Points
• Search terms: complication budget · refresh rate · watch battery