An Honest Word About Timing
“I set 30 minutes—why does it feel like my kid got a few extra?” If you’ve wondered that, here’s the answer with nothing hidden. Straight up:
| Your question | Our honest answer |
|---|---|
| Accurate to the second? | No—power-saving can delay it a few minutes |
| Could it lock before time’s up? | By design, no—we let the gap fall late rather than early. See below |
| Could it miss the limit? | As long as monitoring is running, hitting the limit stops the app |
This one is an honest note for parents. Many parents ask: “If I set a time limit, can Tortoise Time hit it to the exact second?” Our answer is: no — and we’re not going to pretend otherwise. Here’s why, and here are the two lines we never cross.
The short answer: sometimes a few minutes late, by design rather than early
Tortoise Time runs on Android 7.0 and up, and on Android it is the operating system, not the app, that decides when a background app is allowed to think. That’s the whole story in one sentence. The rest of this section is the specifics, sourced from Android’s own documentation, because “phones kill background apps” is the kind of vague claim you should be allowed to check.
The system freezes background apps outright. Android has supported a cached apps freezer since Android 11. When a process is frozen, all of its threads are suspended and can’t perform CPU work until unfrozen. On Android 14 and higher, processes in the cached state are frozen 10 seconds after entering it. Frozen is not “slowed down” — it is stopped. During those stretches an app cannot count anything.
Even the wake-up calls are rationed. When a device is idle, Android’s Doze mode defers alarms, jobs and syncs to periodic maintenance windows, and suspends network access in between. The alarm types built to survive Doze are explicitly capped: Android’s documentation states that neither of them can fire more than once per nine minutes, per app. And the longer a device stays idle, the less frequently the system schedules those maintenance windows.
Apps a child uses rarely get squeezed hardest. Android sorts apps into App Standby Buckets based on how recently and how often they’re used, with progressively stronger restrictions as the bucket gets more restrictive. In the most restricted bucket, an app is allowed one alarm per day.
And then manufacturers add their own layer on top. This part is not just a Chinese-brand problem, which is how it often gets described. The community-maintained project Don’t kill my app! tracks vendor behavior and currently ranks Huawei, Xiaomi, OnePlus, Samsung and Meizu as the most aggressive, with AOSP-based devices such as Pixel among the best behaved. It’s a community project rather than an official source, and worth reading as one — but the ranking matches what we see in testing.
So here’s the real picture: when you set a limit, the reminder will occasionally arrive a little late. If your limit is reached right when the phone has us frozen, the gentle “time’s up” screen may show up a few minutes later than the exact moment in theory. What we do about it — and it’s a real fight — is a separate piece.
The two lines we never cross
We can’t be precise to the second — but two things are locked in by design:
One — the design makes the gap fall late rather than early. We’d rather be “a touch late” than gamble on “probably up by now.” If there’s a stretch we couldn’t see clearly, we treat it as if it didn’t happen, rather than guessing a bigger number and cutting the child off too soon. Being wrongly told “my time isn’t even up yet and I got shut off” feels unfair to a kid.
That’s a design stance, not a precision guarantee. We can’t rule out every system-level surprise, which is why our terms say the gap “may differ from actual time by several minutes, typically appearing as a delay” rather than claiming it never runs early. A flat claim like that only has to be wrong once.
Two — as long as monitoring is running, hitting the limit brings the stop. We’ll own being a few minutes late. What we won’t own is “failing to stop when it should.” Once we’ve confirmed the child has used up the time you set, the gentle stop appears — it doesn’t get skipped just because the phone is saving power.
The condition is that monitoring is still running at all. If the phone has frozen or killed the service outright, that’s a different problem, and we wrote about it separately.
Put simply: the gap typically shows up as a delay, and while monitoring is running, reaching the limit brings the stop.
One consequence worth spelling out, since it’s the thing parents actually notice: the drift lands on the reminders as well as the block. The nudges at 60%, 75% and 90% of the limit can arrive a little later than the arithmetic says, which is one more reason the design leans on several of them rather than a single countdown — the reasoning is here.
We wrote this boundary into our Terms
We’ve never claimed “to-the-second precision” or “millisecond monitoring” anywhere in our marketing. Instead, we wrote this “it may run a few minutes late” boundary plainly into our Terms of Service.
Why put it in the Terms? Because we believe a tool that helps manage your child’s time has no business hiding its own quirks. If it won’t even tell you where its margin of error lives, why should you trust it with the person you care about most?
Promising “perfect precision” is easy. When that promise breaks on a battery-hungry phone, you’re the one left disappointed. We’d rather get the awkward truth out of the way first.
It’s also worth knowing that nobody else escapes this. The constraints above are platform-level: they apply to every screen-time app on Android, including Google’s own. What differs between products is only whether they tell you. When we compared what each vendor documents about its own timing and warnings, most of them simply don’t say.
One line for parents
If what you need is a tool that cuts off to the exact second, Tortoise Time may not be the best fit — we can’t do that, and we won’t pretend we can. On Android, honestly, no app can.
But if you can live with “occasionally a few minutes late, but never unfair to your child, and always stopping when it should,” then we’re worth a try.
Telling you honestly where our limits are is, in itself, a way of respecting you.
Written by a parent who builds Tortoise Time, an Android screen-time app for kids aged 6 to 14. It nudges quietly at 60%, 75%, and 90% of the daily limit before blocking anything at 100%. It’s free, with no ads and no in-app purchases. Your child’s screen-time data stays on the phone by default — the only things that leave the device are pseudonymous crash diagnostics and usage events, as our privacy policy says.
Curious what your child sees when time’s up → Gentle Guidance Want to know why phones kill background apps and how we cope → Keeping the App Alive
Sources
Retrieval level noted for each, because it changes how much weight a claim can carry.
- “Optimize for Doze and App Standby.” Android Developers. (Full page retrieved, and the nine-minute figure confirmed by a second fetch. Source for alarms, jobs and syncs being deferred to maintenance windows, network access being suspended, the cap of once per nine minutes per app on the alarm types allowed to fire during Doze, and maintenance windows being scheduled less frequently the longer the device stays idle.)
- “App Standby Buckets.” Android Developers. (Full page retrieved. Source for bucket assignment by recency and frequency of use, progressively stronger restrictions, and the one-alarm-per-day limit in the restricted bucket.)
- “Cached apps freezer.” Android Open Source Project. (Full page retrieved. Source for Android 11 support, threads being suspended and unable to perform CPU work while frozen, and processes in the cached state being frozen 10 seconds after entering it on Android 14 and higher.)
- “Don’t kill my app!” (Full page retrieved. Source for the vendor ranking. Community-maintained open-source project, not an official Google or manufacturer source — treat the ranking as a well-informed community assessment rather than documentation.)
- Tortoise Time’s own behavior, its Terms of Service, and its privacy policy.
Not claimed: an exact number of minutes of drift. It depends on the phone, the manufacturer’s power-management layer, how recently the child used the app, and whether the device was idle — and any single figure we printed here would be wrong on most phones.