Your automation will break on a Tuesday: the Day 2 checklist

Asking five questions before you build turns a silent three-week outage into a text message you get in ten minutes.

Here's the shape of the problem. You pay someone (or yourself, or a tool) to build an automation. It works. It's great. Then eight weeks later a vendor rotates an API key, or a form field gets renamed, or a card on file expires, and the automation stops. Not with an error message on your desk — it just stops. You find out when a customer calls in March asking why they never got a bill for January.

We call this the Day 2 problem. Day 1 is building it. Day 2 is every day after that — the part nobody budgets for and nobody assigns to a person.

So before you approve any automation build, ask these five questions. They take twenty minutes. They're the difference between an automation you own and one that owns you.

1. Who gets told when it breaks, and how?

Not "where are the logs." Who — a named human — and on what device.

In our experience most builds ship with error logging and nothing else, and a log nobody reads is not an alert. The question you want answered is: when this fails at 6:40 on a Tuesday morning, whose phone buzzes?

Our default: every workflow gets a failure path that sends a plain-language message to a channel the owner already reads all day — SMS, WhatsApp, Telegram, or a dedicated Slack channel. Not email; in our experience email is where alerts go to die. The message says what broke, what it was working on, and what didn't happen: "Invoice sync failed. Job #4412 not invoiced. Last success 6:10am."

2. How would you know if it just… stopped?

This is the different, nastier failure. A crash throws an error. A workflow that never triggers throws nothing at all.

The trigger disconnects. The webhook URL changes. The scheduled run gets disabled during someone else's edit. There is no error, because there is no run. Silence looks exactly like "nothing needed doing today," and that's why these outages last three weeks instead of three hours.

The fix is a heartbeat: a second, dumb little workflow whose only job is to check that the first one ran. If the invoicing automation hasn't logged a success in 24 hours, the heartbeat sends you a message. We also send a once-a-day summary line — "12 invoices sent, 2 skipped" — because a number you see every morning makes a zero obvious. You'll notice a missing text before you notice a missing invoice.

3. Whose login is it running on?

Ask who owns the credentials. The honest answer is usually "the office manager's account," or "the contractor who built it used his own API key."

That's a time bomb with three fuses: the person leaves, their password rotates, or their MFA prompt starts landing on a phone nobody has. Our view: an automation should have its own identity rather than borrowing a human's — and that applies to a boring invoice sync with no AI in it at all, not just to the agent builds people write about.

What we do: a dedicated service account or app-specific credential per integration, owned by the business, stored in the platform's credential vault, documented in one place with an expiry date on the calendar. When someone quits, offboarding them doesn't quietly break billing.

4. What's the manual fallback, and who's allowed to run it?

Every automation replaced a manual process. Write down that manual process before you delete it from everyone's memory.

The fallback has to be visible to the owner, not buried in a tool only the builder can log into. Our usual pattern is a dead-letter list: anything the automation couldn't finish lands as a row in a shared sheet or a task list with the customer, the amount, and the reason. If the workflow breaks for two days, you don't lose the work — you get a list of nine rows to clear by hand, and clearing them by hand is a documented five-minute job, not an archaeology project.

Second half of the question: who's allowed to run it. Someone besides the person who built it needs the login, the runbook, and permission to hit the switch.

5. Who owns this in six months, and what's the fix budget?

Automations are not appliances. Integrations change, and in our experience something in a small business's stack shifts under it every few months.

So name an owner and set a number. Our own rule of thumb, as of August 2026: budget roughly 10–20% of the original build cost per year for maintenance, and put a recurring 30-minute calendar block on whoever owns it to walk the alert channel and the dead-letter list. That's our opinion, not an industry benchmark. If nobody will accept that block, you're not ready to build the automation — you're ready to build a future outage.

What three weeks of silence costs

The following is a hypothetical example — our arithmetic, not a client's numbers.

Say a small HVAC company completes 60 jobs a month at an average invoice of $420, and the automation that turns a completed job into an invoice breaks on a Tuesday in early January. Nobody notices for three weeks.

• ~45 jobs done, unbilled: $18,900 of invoices nobody sent
• All of it collected at least three weeks late, and later still if you bill net 30
• Reconciling by hand afterward, at, say, 8 minutes per job: 6 hours
• Some of those customers now argue about a bill that showed up a month after the visit

Put the automation's own cost at $200/month in this hypothetical and the arithmetic is lopsided: one silent outage delays more cash in three weeks than the tool costs in a year, and adds six hours of cleanup. None of that was the automation's fault. It was the missing alert.

What we actually build, and what it costs

On our builds the Day 2 layer isn't an upsell, it's part of the job:

• A failure path on every workflow that texts a named human in plain language
• A heartbeat workflow that alerts on absence of runs, not just errors
• A daily one-line success count to the owner's phone
• A dead-letter sheet the owner can see and clear without a developer
• Business-owned credentials, documented, with renewal dates on a calendar
• A one-page runbook: what it does, what breaks first, how to do it by hand

On a typical single-workflow build, that's a few hours of setup — call it 10–20% on top of the build — and it usually runs on the same platform subscription you're already paying for, so no new monthly line item. That's our pricing approach as of August 2026; platform plans and prices change, so check yours before you budget.

The twenty-minute version

If you take one thing: before you approve the next automation, make whoever's building it answer, in writing, five lines.

1. On failure, this texts ____.
2. If it silently stops running, we find out within ____ hours, because ____.
3. It runs on ____'s credentials, which expire ____.
4. When it's down, we do the work by hand like this: ____. The list of skipped items lives ____.
5. ____ owns it, checks it ____, and has $____ a year to fix it.

If any line comes back blank or vague, you've found your Tuesday.

---

Bring us the one automation you're most nervous about. On a strategy call we'll walk your workflow through these five questions and tell you which alerts and fallbacks it's missing — no build required. Book a strategy call.