What Breaks a Weekly Report Automation — and Who Fixes It at 6 A.M.

A weekly report automation almost never breaks in the automation. It breaks upstream — someone renames a column in the export, a password expires, a new job code shows up that the logic has never seen — and the report still sends, on time, quietly wrong. The thing that determines whether that costs you an afternoon or a customer is not the quality of the AI. It is whether anyone is watching, and whether the person watching is you.

What actually breaks a weekly report automation?

After enough of these, the failures stop being surprising. They cluster into a short list, and none of them are exotic:

• A source file changes shape. Someone adds a column to the weekly export, or renames “Job #” to “Job Number,” and the mapping that fed the report no longer finds it.
• A credential expires. An API token, a password rotation, an MFA policy change — the automation is fine, it just can’t log in anymore.
• New data the logic has never seen. A new job code, a new customer, a new cost center, a division that starts using a second system. The rules were written against last quarter’s reality.
• A silent zero. A query returns no rows because of an upstream delay, and the report cheerfully publishes $0 in revenue for a week that had plenty.
• A human process change. The ops lead starts logging something in a different field, or a crew moves to a new app, and nobody thought to mention it because it wasn’t an “IT change.”

Notice what is missing from that list: the model, the prompt, the clever part. The clever part is the part that almost never breaks. Plumbing breaks. That is the whole reason we spent six years cleaning small-company data before we ever pitched anyone AI — the failure modes here are data failure modes, and they are old.

Why is a wrong report worse than a missing one?

When a report doesn’t arrive, somebody asks where it is. That is a self-announcing failure, and it gets fixed inside a day. When a report arrives on time and is wrong, it gets read, forwarded, and acted on. Your controller reconciles against it. Your customer quotes it back to you.

This is the specific risk that comes with automating something a person used to do. The person was, without anyone writing it down, also the quality check. They would have noticed that Tuesday looked strange. Automate the assembly without replacing the noticing, and you have made the process faster and more confident at the same time — a bad combination.

How do you find out it broke before your customer does?

Monitoring a report automation is not the same as monitoring a server. “The job ran successfully” is close to useless here — the job runs successfully in almost every failure above. What you want checked, every single run, before anything sends:

1. Did every source actually return data, and roughly as much as last week? A 90% drop in row count is a red flag even when the query succeeded.
2. Did anything arrive that the logic doesn’t recognize — a new code, a new customer, an unmapped field? Unknown inputs should raise a hand, not get silently dropped.
3. Do the totals reconcile against a second source you trust, even loosely? Revenue against the accounting system, hours against payroll.
4. Is the shape of the output sane? Blank sections, zeroed columns, and a report that is suddenly half its usual length are all detectable without knowing anything about the business.
5. Did a human get a chance to look before it went out — and is skipping that step a deliberate choice rather than an accident?

None of that is sophisticated. It is the checking the person used to do in their head, written down and made repeatable. It is also the part that gets cut first when an automation is scoped as a one-time build.

Who fixes it — and how fast?

This is the question worth asking any vendor, tool, or contractor before you sign anything, because the honest answers differ enormously.

If you built it yourself with a workflow tool, you fix it, and you find out on Monday. If you bought reporting software, the vendor keeps their product running — but the thing that broke was your export, your credential, your new job code, and that is outside their support boundary. They will tell you so, politely, and they will be right. If you hired someone for a fixed-scope build, the automation belongs to you the moment the invoice clears, which means the 6 a.m. phone call is yours too.

That gap is the actual reason we price Standing Reports as a monthly service rather than a build fee. Not because a build is hard to quote — because the first six months of small breakages are the part that decides whether the report is still running a year later, and nobody wants to be nickel-and-dimed for a renamed column. Monitoring, fixes, and format changes are inside the price. If you want the wider comparison of who can do this work at all, we wrote that up in your three options, compared.

What does the maintenance actually cost?

Less than people fear, and more than zero. A recurring report wired into two or three systems typically needs a handful of small interventions in its first quarter — a mapping update, a re-auth, one new category — and then settles down. The work is measured in minutes per incident once someone knows the system. The expensive part was never the fixing. It was the not-knowing.

That gap in the second number is not really a technology gap. Bigger companies have someone whose job includes noticing when a report is wrong. Smaller ones are absorbing that by hand — which is exactly why the monitoring, not the automation, is the part worth buying.

Four ways to get a recurring report, compared

Every option below works for somebody. The question is not which is best, it is who is on the hook when it breaks — because that is the row most comparisons leave out, and it is the one that decides how much of this actually lands back on you.

If somebody on your team already owns reporting as part of their actual job description, buy the software — it is cheaper and it will work. The done-for-you option earns its price only when nobody's job description contains the words "fix the report." See what Standing Reports covers for where that line sits.

Frequently asked questions

How often does an automated weekly report actually break?

Expect a few small interruptions in the first quarter while the automation meets edge cases the original spec never saw, then long quiet stretches punctuated by whatever changes upstream. Credential expiries and source-format changes are the two most common causes, and both are external to the automation itself.

Can’t the AI just handle the changes automatically?

Sometimes, and that is the risk. A system flexible enough to silently absorb a renamed column is also flexible enough to silently absorb a wrong one. For anything that touches money or customer commitments, we would rather the automation stop and ask than guess well most of the time.

Who should own the monitoring — us or the vendor?

Whoever is going to notice at 6 a.m. If your team has someone who reads the report closely enough to catch a bad number, owning it internally is reasonable. If the report goes straight to a customer or a lender, you want monitoring that runs before the send, owned by whoever can also fix it.

What happens to our report if we stop working with you?

You keep the work. We build inside the systems you already own and hand over the logic, the access, and the documentation — no proprietary box you have to keep renting to read your own numbers. Month to month means month to month.

More on how we scope this kind of work is on our services page, and the reporting service itself is detailed on Standing Reports.