Where your automation actually runs
The machine has to be awake
An automation is a program, and a program needs a computer that is powered on, connected, and awake at the exact minute the work is supposed to happen. That reads as obvious until you count how much automation failure traces back to it. The fleet behind this firm logged 2,668 runs in the last thirty days and 12,773 since it started, and the least interesting prerequisite for every single one was a machine that happened to be running at the time.
So the hosting question comes before the tool question. Where an automation lives sets the reliability ceiling for everything built on top of it, and no amount of clever prompting raises that ceiling later.
The laptop problem
First automations almost always get built on the laptop of whoever built them, because that is where the code already sits. It works. It keeps working for a few weeks. Then a lid closes on Friday at five, the Saturday morning job never fires, and nobody notices until Monday.
The variations are all boring. The machine goes to sleep. A system update reboots it at 2am and leaves it sitting at a login screen. The office internet drops for an hour. Somebody signs out of the account the job needed.
What makes this category worse than a normal bug is that a job which never starts produces no error. Error monitoring watches for things that fail. Nothing is watching for a run that simply did not happen, which is a different problem from the bad output covered in why automations fail silently. The check you need expects a run at 7am and complains when nothing arrives.
So a laptop should not host anything another person depends on. The objection is availability. A laptop is built to be off most of the time, and it is very good at it.
The fair exception is your own personal automations. If the only person affected by a missed run is you, the machine you already own is a reasonable trade, and it is where most of the personal work starts.
Three honest places for it to live
For a small business the real options are short, and each one trades something away.
- A machine that stays on where you work. A small desktop in the back office, set to never sleep, on a battery backup. Cheapest option, and you can walk over and look at it. It also inherits your power and your internet, which are probably the two least reliable things you own.
- A small cloud server. Someone else's power, someone else's internet, both better than yours, and nothing physical to trip over. You give up the ability to walk over and look at it, so the logging has to be good enough to answer the question remotely.
- Inside software you already pay for. Plenty of tools have a scheduler built in. Fewest moving parts and nothing new to maintain, but you get their schedule granularity, their limits, and their outage on the day they have one.
Decide what a missed slot means
Every scheduled job needs an answer for the run it eventually misses, because it will miss one. There are two sane behaviors, and picking the wrong one causes its own damage.
Some work catches up. An invoice follow-up that should have gone Tuesday is still worth sending Wednesday. Some work expires. A 7am summary of yesterday's email is worthless at 4pm, and the right move is to skip the slot and report that it was skipped. The failure we have hit on our own fleet is making everything catch up by default, so a machine coming back from an outage fires a queue of stale work all at once and a customer gets their Tuesday follow-up at 3am on Friday.
Write the choice down per job, in the same place as the plain-English description of what that job does. It is one more line in the handoff doc and it saves an ugly morning later.
What to ask before anyone builds for you
Ask what machine this runs on, who owns that machine, and how long it takes to move the automation to a different one. The last question separates a working setup from a fragile one. If the answer involves remembering how it was originally configured, the setup exists only in someone's memory, and the next hardware failure turns into a project.
A well-built automation should move to a new machine in an afternoon, because every step of its setup got written down while it was being built. Where ours live, how they report in, and who gets told when one goes quiet is the managed service.
The audit answers this for your business
Two weeks, $2,500 flat ($1,000 for the first three clients), and you get the map of your own automatable work with dollars on it.