Think of it as a small dictionary you can keep next to your automations.
Most of the time, you’re trying to answer just three questions: did it run, did it do the right thing, and did it cost more battery/time than it should.
Before you dive in, it helps to know where these numbers usually come from on Android: an automation app’s history screen, Android’s battery/per-app usage, notification logs, and sometimes the target app’s own “last synced” or “activity” timestamps.
Trigger vs event vs condition: what actually starts an automation
Trigger: the “starter pistol.” A specific thing that tells the automation to begin (example: “when I connect to my car’s Bluetooth”).
- Event trigger: something that happened (connected to Wi‑Fi, received a notification, time reached 7:30).
- State trigger: something that is true right now (battery is below 20%, screen is off).
Condition: a gate that can stop the run even if the trigger fired (example: “only if it’s a weekday”).
Action: what the automation does after it starts (toggle a setting, send a message, start playback).
If you’re seeing “it didn’t run,” first ask: did the trigger fire, or did a condition block it?
Runs, executions, and success rate: what “worked” really means
Most apps show a count like “runs” or “executions.” That typically means the automation started, not that it finished cleanly.
Run / execution: one attempt from start to stop (even if it stopped early).
Success: tricky. In many tools, “success” can mean “the app didn’t crash,” not “the outcome happened.” For example, an automation may “successfully” try to toggle a setting that Android blocked.
Success rate: successes divided by runs. Useful only if “success” is defined the way you care about.
Practical approach: pick one observable result and treat that as the real success signal (a notification posted, a file created, a message sent, a system setting changed).
Latency, delay, and schedule drift: why “it ran late” happens
Latency: how long it takes between the trigger moment and the action actually starting.
Delay: an intentional wait you configured (example: “wait 2 minutes, then…”).
Schedule drift: when a time-based automation slowly stops matching the clock (example: a “every 15 minutes” task gradually fires at :03, :19, :36). Drift usually comes from batching, sleep/idle modes, or the system deciding to run work “when convenient.”
On Android, late runs are commonly caused by battery optimization, background restrictions, Doze/idle behavior, or the target app not being allowed to run in the background.
Errors, failures, timeouts, and retries: what kind of break you’re seeing
When something breaks, the label tells you where to look.
- Error: the automation tool hit a problem it recognized (missing permission, couldn’t read a file, API denied).
- Failure: often a generic “it didn’t complete,” sometimes without detail.
- Timeout: it waited for a response too long (network slow, target app not responding, system blocking background work).
- Retry: the tool tries again automatically after a failure/timeout.
- Backoff: retries get spaced farther apart (to avoid hammering the network or draining battery).
A useful mental model: timeouts point to waiting on something external; permission errors point to Android settings; repeated failures point to a logic bug or a changed screen/app behavior.
Battery cost and “background work”: the metrics that matter on Android
Foreground vs background: foreground work happens while you’re actively using an app; background work happens while it’s not on screen. Android is stricter about background work to protect battery.
Wake: the device (or CPU) is kept from sleeping. Lots of wakes can equal lots of battery drain.
Wake lock: a mechanism that forces the CPU to stay on for a task. Some automation actions need it briefly; persistent wake locks are a red flag.
Battery optimization: Android may delay or stop background tasks for apps it thinks aren’t “important right now.” If your automation app is optimized, “runs late” becomes more likely.
Rule of thumb: prefer fewer runs that do more work (batching) over many small runs that constantly wake the phone.
A quick checklist: translate a confusing log into a next step
If you’re staring at a history screen and not sure what to do, use this short flow.
- Runs are missing → the trigger didn’t fire (or the app was blocked). Verify trigger source (Bluetooth/Wi‑Fi/notification) and background restrictions.
- Runs exist but outcome didn’t happen → “success” is meaningless here. Add a visible confirmation step (notification, timestamp note, file write) to prove the action completed.
- Runs are late → check battery optimization and background limits first; then check drift (time-based) vs latency (event-based).
- Timeouts → suspect network, target app sleeping, or the system delaying background work. Consider longer timeouts or fewer network calls.
- Many retries/backoff → you likely have an unstable dependency (spotty Wi‑Fi, rate limiting, notification access issues). Fix the dependency before adding more retries.
- Battery drain → look for frequent triggers, tight polling loops, repeated failures, or actions that keep the phone awake.
One small change that helps: keep a note of “expected runs per day.” If you expected 4 and you see 120, you’ve found your real problem.
Takeaway: the two numbers to trust (and the one to be skeptical of)
Trust: run count over time (is it firing too much or not at all) and observable outcomes (did it produce the thing you wanted).
Be skeptical of: success rate unless you know exactly what “success” means in that tool.
Once you translate the terms, most Android automation debugging becomes a simple choice: fix the trigger, fix permissions/background limits, or reduce the work (and battery cost) per run.