What happens when your automation breaks — and who carries that cost?

When your automation breaks — and it will, eventually — who absorbs that failure?

In most systems, your client does. The broken link lands in their inbox. The replay never arrives. The follow-up that didn't fire means they never hear from you again after they signed up. They have no idea your platform glitched. From their side of the screen, you just didn't show up.

Your dashboard says: successful send. Their experience says: something went wrong and no one noticed.

This week is error-proofing and client journey design — the mechanics from last year's arc, plus the question I wish we'd named sooner: how do you host people well when the tech is doing most of the talking?

Hospitality is what keeps this human. A backup plan you can read without logging into five dashboards is what keeps you from spiraling when (not if) something goes wrong.

~3 min read

These are the fundamentals. If you built any of them from the 2025 arc, give them a checkup. If you have not built them yet, start here.

Failure notifications that go somewhere you actually check.

Every automated sequence you run needs a failure alert that lands where you will see it within a reasonable window. Not buried in a platform dashboard. Not in an email folder you skim monthly. Your Slack. Your phone. A recurring task that prompts you to check.

If an automation fails and you find out two weeks later, the failure notification is not doing its job.

A written backup plan for each automation.

One sentence per automation, somewhere you can find it: If this fails, do X manually within Y hours.

Not a contingency policy document. A plain note. When the automation breaks at 10pm before a morning event, you want to know exactly what to do without having to reason it out from scratch.

A weekly status check.

A five-minute recurring task: open your automation platform, look at recent runs, scan for anything flagged. This is not a deep audit. It is the equivalent of checking that the oven is off before you leave the house.

Client-side testing.

Before you launch a sequence, complete it as a client would. Click the confirmation link from the email. Open the reminder on your phone, not your admin desktop. Test the replay URL before you send it in a follow-up. What the admin view shows you and what the client experiences are not always the same thing.

Once your failure notifications are in place, map the journey the way you would if a guest were walking through your front door. Your platform's diagram is useful. It is not the same thing as asking whether someone feels welcomed.

Hosting means repeating what matters.

Where does critical information live in exactly one place? A Luma confirmation that is the only email with the event link is a single point of failure. If that message gets buried, the link is gone and your guest is standing outside wondering if they got the date wrong.

Repeat the event link in the confirmation, the reminder, and the day-of note. Repeat the replay link in the follow-up and again a week later for the people who meant to watch and life intervened. Good hosts do not make people hunt through their inbox for the one message that counted.

The assumption audit — with compassion for heavy weeks:

Mark every place your sequence assumes the client will do something: add to calendar, save the resource page, remember to reply if they have questions.

Some will. Many will not — not because they do not care, but because their week got loud and your system quietly expected bandwidth they did not have. Hospitality is removing friction so they do not have to perform executive function on your behalf.

A check-in is not a sales pitch.

Does your sequence end with a hard stop? A single "are you still coming?" before an event — plain language, no urgency theater — is one of the most human things you can automate. Most creator stacks skip it. Your guests notice when you do not.

Digital sovereignty — the folder that outlives the tool:

I keep cadence, templates, backup plans, and client-journey notes in a real folder on my machine — Markdown files I can open whether ConvertKit is up, whether Luma changes a URL, whether the platform I used last year still exists.

That is a backup plan for me, not just for the automation. If one service has an outage or shuts down, I still have the rhythms document, the confirmation template, the one-sentence "if this fails, do X by Y" notes. I can re-send from Gmail. I can paste into a new tool without reconstructing my system from memory at 10pm.

You are not married to today's stack. You are building a structure you can carry into whatever tool you use next month. Sovereignty sounds grand; practically it means you do not have to overthink when something breaks — you open the folder, read your own words, and host your people anyway.

The April 26 event went well. Maya attended about halfway through, got interrupted by a family thing, and closed the tab.

Two weeks later she wanted the rest of the replay. She searched her email for the original confirmation. She found it. She clicked the resource page link.

The URL had changed when the creator restructured their site after the event. The confirmation was never updated. The automation logged a successful send. The link worked on send day. By the time Maya needed it, hospitality had already failed — and nobody was notified.

Maya closed the browser. She did not send a "hey the link is broken" email. She just did not watch the rest. The creator has no idea.

That is the cost of a system that treats "delivered" as "done." Maya experienced abandonment. The dashboard experienced success.

A host who keeps a literal folder — current links, replay URL, backup send instructions — would have caught this in a five-minute pre-send check, or recovered in one manual email. The tool did not fail loudly. The hosting did.

Reflection prompts:

If the answer to the last two is "rarely" or "only when something breaks," that is useful data. Hospitality includes testing the guest path, not only admiring the admin view.

If you followed Your IDE Is a Workbench, you may already have my-rhythms.md on disk. This week adds the next sovereignty move: a template file you own outright.

Pick one message you rewrite from scratch every time — event confirmation, newsletter intro, follow-up — and save it as Markdown in a templates/ folder. Name it clearly: event-confirmation-template.md.

Next time you need it, you open a file instead of reconstructing from memory. In Chat, type @event-confirmation-template.md and ask the AI to fill in dates and links from your structure. When a platform changes, you update the file once; the hosting stays consistent.

Open the terminal panel (Control + backtick). Type ls and press Enter. Same folder as the sidebar — listed from the command line. You are not coding. You are confirming that your backup plan lives somewhere you can see and copy from even when a vendor dashboard is down.

This is the U in O.U.R. Context: usable, portable, yours.

Full written guide — @mentions, Apply, templates, and terminal basics coming next week!

Haven't opened the IDE yet? Week 1 video · VS Code workbench blog.

Your tech struggles, reflected back. Got one? Send it in.

This week's prompts (pick one or answer all):

What is the most common way your systems fail your clients that they probably never tell you about?

How many times do you click every link when your page or newsletter goes live — and on how many devices?

Hit reply. I read every one.

The Fire Horse builds so the noise reaches you first — and so your guests are not left guessing in the dark.

Pick one automation and ask: if this fails tonight, would I know by morning? If the answer is no, that is your next fifteen minutes.

Then ask the hosting question: if the platform vanished tomorrow, do I still have the cadence, the template, and the manual send path in a folder I control?

Write one sentence per automation: If this fails, I do X manually within Y hours. Put it where you will actually look. That is sovereignty you can keep tangible and share with future you and your team.

🔥 Charge forward with: Click every link in your last confirmation email — on your phone — before you send the next one.

Next Friday: Your Automation Playbook — the One Document That Holds Everything.

We wrap the arc, do the Y.O.U.R. self-assessment, and build the one concrete thing you carry out of May. And we find out how Maya's story ends — in the version where the system did its job.

Plus: the final video and blog publish together — @mentions, rules, AGENTS.md, playbook, and GitHub Desktop for beginners.

And then: May 31, 3:30pm ET. One week from this Sunday. Bring your actual automation, your actual questions, and your actual broken sequences. We are doing it live.

Register: luma.com/indojpzh

If anything in today's issue landed for you, hit reply. I read every one.

See you next week.

— Amanda

The Pythoness Perspective is free, always. If it's useful to you, here are ways to support the work: