The login your automation borrowed
Every automation logs in as somebody
Every automation that reads your mail, posts to your accounts, or pulls from your software is logged in as somebody. When that login stops working, the job stops with it. The things that end a login are ordinary: a password reset, a person leaving, a session that lapses overnight.
So the fix is bookkeeping. Write down whose login each job runs on, stop hanging jobs off one person's everyday account, and make a lost login fail loudly enough that someone reruns the missed work. A locked front door is obvious by 8 AM. An automation that cannot sign in often is not.
Two lost logins on this machine
On the night of July 31 the login for the AI tool that runs most of the scheduled work here lapsed. Every job that fired between 10 PM and 7 AM checked for a working login, found none, wrote one line saying so, and quit. Six jobs hit it. Each was finished in somewhere between one and six seconds.
The login was working again by the next afternoon. One of the six got rerun by hand. The other five did no work that night, and their output for August 1 does not exist. That case had no fallback and no retry, so every abort was a total loss for its run.
The second one started with a person doing something sensible. On August 24 a password was reset on a mail account one of our automations reads. The mail provider treats a reset as a cutoff, so every connection granted before that moment stopped working, ours included. The step that checks website leads against that inbox went blind. It was confirmed working again on September 1, eight days later.
A dead login finishes fast
Both failures share a signature, and it is the cheapest check there is. A job that normally takes four minutes and finishes in three seconds did not do its work, whatever its exit status says.
Record how long every run takes and compare it to that job's own normal. A run at a tenth of its usual time deserves a look even when it reports success. The July aborts at least admitted they failed. Plenty of scripts catch the sign-in error, write a warning to a log nobody opens, and exit clean with nothing produced.
Then plan the catch-up. A lost login takes out everything scheduled while it lasts, so when access comes back somebody needs the list of what fired during the gap and a call on each item. An invoice reminder is still worth sending a day late. A 7 AM summary of yesterday's email is worth skipping and saying so, which is the same choice covered in where your automation actually runs.
A check that found nothing may have looked nowhere
Logins also fail in a quieter way. The job signs in fine, as the wrong somebody.
The mail tool here connects to more than one account and falls back to one of them when no account is named. On September 11 a search meant to sweep one inbox ran without naming it, came back clean, and looked complete. It had searched a different mailbox. Nothing errored, because from the tool's side nothing was wrong.
There is also a mailbox no connection here can read at all. Inquiries for one business land with a person whose account was never shared, so any check on that business's leads rests on the CRM alone. That is acceptable as long as the report says so. It turns into a problem the day somebody reads no missed leads as proof the inbox was checked.
The habit that covers both is making every job name, in its own output, the account it actually used. A result that says which mailbox it searched is a result you can argue with.
Put the login next to the job
The inventory takes an afternoon. List each automation. Next to it write the account it runs as, whose password that is, and what would end it: a reset, a departure, a new sign-in policy, a lapsed subscription, a token with a built-in expiry. Then write down who re-grants access when it breaks, and how long that takes when they are on vacation.
Anything tied to one person's everyday account breaks in a predictable way, on the day that person changes a password, leaves, or replaces their phone. Where you can, move those jobs to an account the business owns and nobody uses for their own mail, with access limited to what the job needs. Those are the same rules as an owner's guide to API keys and the same logic as automation that survives turnover.
Mapping which account every job leans on is part of an AI ops audit. Noticing the Tuesday one of those accounts stops answering, and rerunning what it missed, is the month to month side of the work.
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.