Key takeaways
- Our automations run overnight with nobody watching, and the only thing any of them produces is a row in an approval file. None of them can tell you what they did.
- So the front page of our internal app reads the last week of those rows, groups them by day and by whichever assistant owns the work, and reads like a shift handover from a team that was never in the room.
- Ownership is pattern matched off the name each automation writes about itself. There is no registry, so a lane with an unfamiliar name lands on the default and looks like work somebody else did.
- Naming a new lane after the work it does is therefore not a style choice. It is how the report stays truthful.
- The same page carries how deep each content queue is and whether anything died quietly, because a day with no rows is ambiguous until you know which it was.
We run a lot of unattended work. Nightly builds that fill tomorrow's posting slots, blog lanes, a picker that stages one question for one group, a news sweep, episode builders for the faceless channels. All of it fires while nobody is looking at a screen.
Which creates a strange problem. The work happens, and there is no way to ask how it went. A headless job has no face and no voice. It finishes, it exits, and the only trace is whatever it wrote down.
The only thing they all produce
Every automation here that stages something a customer would see writes one row into a single approval file. That is a hard rule for a different reason, which is that nothing publishes without a human saying yes. But it has a side effect worth more than the rule: there is exactly one place where all of the overnight work leaves a mark, in the same shape, whoever wrote it.
Each row carries a date, the name of the source that wrote it, what was built, where the draft lives, and a status. That is enough to reconstruct a night.
So the app's landing page reads the last seven days of those rows and rebuilds them into a handover. Rows group by calendar day, and within a day by which of our nine assistants owns the source that wrote it. Each day shows how many items landed, how many are still waiting on a decision, how many actually shipped, and what any of it cost in generation credits, which the rows state in plain words and the parser adds up.
The routing is the part worth explaining
Assigning a row to an assistant sounds like the easy half. It is the half with the trap in it.
There is no registry mapping automations to owners. The source cell is free text that each automation writes about itself, so ownership is decided by pattern matching that text against a list of rules in order, first match wins. Anything mentioning a blog, a channel, a radar or an episode belongs to the studio assistant. Anything mentioning a social lane, a reel, a story or a group belongs to short form. Leads, pipeline and applicants go to the pipeline assistant. Sites, deploys and landing pages to the web one.
And anything that matches nothing at all goes to the default.
That last line is the whole gotcha. A new lane with a name nobody thought about does not fail loudly or appear in an error list. It quietly attaches itself to one assistant's column, and the handover then shows that assistant doing work they never touched. The report stays perfectly readable while being wrong, which is the worst failure mode a report can have.
The fix is not a smarter matcher. It is that a new lane gets named after the work it does, so it matches the rule that already exists. That turns a naming convention from a tidiness preference into something the system depends on.
Rows are only half the picture
A day with no rows on it is ambiguous. Either nothing needed approving, or the thing that produces approvals did not run. Those look identical on a handover.
So the same page carries two more things. It reads each content queue and reports how many items are still ahead of now and unfired, when the next one goes out, and how many of those are still waiting on a yes. A queue that has dropped to nothing when our own manifest says it should be days deep is flagged, because that means the build either did not run or ran and produced nothing.
Then it runs the fleet health check and shows the verdict. That check is slow, so its result is cached for ten minutes and only one run is ever in flight at a time, however many people open the page.
Between the three, an empty day is no longer ambiguous. No rows plus healthy queues plus a clean verdict is a quiet night. No rows plus a queue at zero is a job that died.
What this means for your business
You already have unattended work, even without automations. Somebody covers the phone while you are on a job. A booking form takes enquiries at midnight. Work happens while you are not there, and the question is always the same one: what did I miss.
The transferable idea is that you do not need every system to report. You need one place they all leave a mark, in a consistent shape, and then a view that reads it. Most small businesses have the opposite: five places where things happen and no place where they are collected, so the only way to know what happened is to remember to check each one.
The second idea is the ambiguity one, and it catches people running Go High Level Bay Area workflows constantly. Quiet is not the same as fine. If your dashboard shows nothing today, make sure you can tell the difference between nothing happened and nothing is running.
Want this built for you
We build the automations and the pages that tell you what they did. Websites, funnels and CRM systems for Bay Area businesses. Start at optechsol.llc.