Short answer: automations rarely break because Shortcuts is buggy. They break for three mundane reasons — the Ask Before Running switch is on, an update reset the permissions you granted, or an app changed its own interface. All three are diagnosable in a couple of minutes, and none of them require rebuilding the shortcut from scratch.
This is worth saying plainly because the advice online is mostly "here are 50 automations you should build", which is the opposite of useful. The hard part of automation is not creating it — it is keeping it working, and the reason most people quietly abandon their automations is that they never learned to tell those three failure modes apart.
The three reasons automations stop working
1. Ask Before Running is still on. This is the most common cause by a wide margin, and the most annoying because it is not a failure — the automation runs, it just stops to ask. When you create an automation, iOS enables this by default for most trigger types. The automation then behaves like "offer to do the thing" rather than "do the thing", and after a week of tapping a notification you conclude that automations are pointless.
Open the automation and look for Ask Before Running. Turning it off makes time- and location-based automations genuinely silent.
2. An iOS update reset the permissions. Shortcuts actions often need access to something — Photos, Files, Location, Health, or another app's data. The first time a shortcut runs, iOS asks and you grant it. That grant is not always permanent: after a major update, or after the shortcut's actions are edited, iOS may ask again. An automation that runs unattended cannot answer a prompt, so it fails silently.
How to tell this one apart from the others: run the shortcut manually (tap it in the Shortcuts app). If a permission prompt appears, that is your answer, and it was never an automation problem.
3. The app on the other end changed. Shortcuts actions that talk to third-party apps depend on an interface those apps control. When an app updates, that interface can move: a URL scheme gets renamed, a parameter changes, an action is deprecated. The shortcut does not break loudly — the step simply stops producing what the next step expects.
Run it manually again. If it fails at one specific step, and that step touches a third-party app, you have found it. The fix is usually to delete that action, re-add it from the updated app, and reconnect the variables.
The two-minute triage. Run the shortcut by hand. Prompts for permission → cause 2. Fails at one step → cause 3. Runs perfectly by hand but not on schedule → cause 1.
The automations actually worth maintaining
The honest test is not "is this clever" but "does this save a tap often enough to be worth the upkeep". Automations that fire daily and replace three or more taps earn their place. Automations that fire monthly, or that save a single tap, do not — you will forget what they do before they pay for themselves.
The categories that tend to pass that test:
| What it does | Why it survives |
|---|---|
| One-tap evening routine — Do Not Disturb on, alarm set, a few app-level settings changed | Replaces several separate trips into Settings, and runs at a time you are reliably present for |
| Photo or screenshot handling — resize, strip metadata, save to a specific album | Runs often, and the manual version is fiddly rather than merely slow |
| Quick capture — save current location, log a timestamp, append a line to a note | Uses data only the phone has, and beats opening an app to type |
| Arrival or departure routines — switch settings when you reach a place | Location triggers genuinely save a habit you would otherwise forget |
Compare that with the automations that circulate online — "text your contact when you reach home", "auto-post to social media" — which either need a confirmation step anyway or run into the deliberate limits described below. They look impressive and get abandoned.
Where the limits are, so you stop fighting them
Two constraints are worth knowing, because most "broken automation" complaints are actually one of these:
- Triggers based on inbound content are restricted. An automation cannot quietly read your messages or email and act on them. iOS does not allow it, and no amount of shortcut-building gets around it. If your automation depends on receiving a message, expect it to involve you.
- Some actions still require the phone to be unlocked, or an app to be foregrounded. Anything that drives another app's interface is at the mercy of that app's own behaviour.
Once you know these are by design, the productive move is to redesign the automation around them rather than keep re-creating it and hoping. If your goal genuinely needs one of these, a manual shortcut you trigger yourself is usually the better answer — see App Permissions Explained for why those limits exist at the system level.