--- title: "How I use scheduled Codex jobs to build daily reports" date: 2026-08-06 description: "How deterministic tools, scheduled Codex jobs and inspectable HTML fit into two daily reporting workflows." tags: - "codex" - "automation" - "analytics" - "llm-agents" --- I have now built two daily reporting workflows around scheduled Codex jobs, and they have turned out to be surprisingly useful. This is the first time I have used the feature for something sustained, and the two projects have settled into roughly the same shape. The numbers and repeatable transformations stay deterministic. Codex runs and inspects that machinery, makes a small amount of judgement where it is useful, and produces an HTML artefact I can review. The report is personal rather than generic, and the whole pipeline remains visible when something goes wrong. That is the pattern I find interesting. The particular graphs, Raycast shortcut and daily findings are examples of how I am using it, rather than the whole reason for the approach. ## A useful shape for scheduled reporting A normal scheduled script could collect most of this data. I used to think these jobs should be left entirely to deterministic tasks, and I still kind of agree. The useful division is to keep collection and calculation exact, then [put the model around those steps](/posts/llm-better-building-322-solver/). A [scheduled Codex job](https://openai.com/academy/codex-automations/) can run the existing commands, inspect their result, follow a bounded recovery rule and decide how to present what happened. In a more editorial workflow it can also make evidence-limited selections that would be awkward to encode as a fixed ranking or scraper. The output matters just as much as the scheduled run. Both of my jobs end by writing a self-contained HTML file. There is no chat transcript to reconstruct and no pile of terminal output to interpret. I get a stable artefact with the source state, dates, caveats and useful comparisons in the same place. The model does not make an unreliable metric reliable. It gives the deterministic system a flexible orchestration and presentation layer. ## billiem-analytics keeps the numbers exact The more deterministic example is billiem-analytics. It collects website visitors, edge traffic, [Google Search Console](https://support.google.com/webmasters/answer/7576553), DEV and Hashnode into dated local snapshots, then rebuilds one private HTML dashboard. Those sources do not all contain the same kind of metric. Website and search data are daily flows, while DEV and Hashnode expose cumulative publishing counters. The dashboard keeps those differences visible instead of flattening everything into one false comparison. It also distinguishes a real zero from an unavailable source, a missing configuration and a failed collection. The result is the overlay I wanted: nice graphs, consistent reporting periods and explicit source health. It is a view that works for me as an individual rather than a generic provider dashboard. One recent use was seeing, in one place, how things had tailed off while I was not publishing. Previously I would have needed to open several browser windows and line up the dates myself. The information existed, but the path to it was painful enough that I often did not bother. I added the report to [Raycast](https://manual.raycast.com/quicklinks), so typing `analytics` opens it in Chrome and regenerates it as appropriate. That shortcut is a small implementation detail, but it makes the final artefact almost frictionless to reach. ## Founder Brief uses more judgement Founder Brief uses the same broad pattern with a less deterministic middle. A Python collector gathers and ranks candidate material into an editorial packet. The scheduled run reads that packet, inspects the strongest sources and useful discussion branches, rejects weak or promotional material, and writes a small evidence-limited briefing. The final HTML includes the selected findings and their limitations rather than pretending the source coverage was complete. That work benefits from judgement. A fixed scraper can retrieve known fields and a ranking can control reading order, but neither decides whether an anecdote is actually useful, whether two observations form a pattern or whether a source gap makes a conclusion too strong. The model can make those decisions against written editorial rules while the candidate IDs and validation keep the result inspectable. It can also use web search without pretending that it can get through every site. Authentication, access controls, rate limits and format changes can still stop Codex. The workflow explicitly avoids bypassing those boundaries and reports unavailable sources. Flexibility is not the same as guaranteed access. Again, the end of the process is deliberately unglamorous: just chuck it on an HTML file. ## Cheap models around reliable tools The argument against this setup is reasonable. If most of the work is deterministic, putting an LLM in the scheduled path can look over-engineered. For me, tokens feel cheap enough that the extra layer is worth trying, and this does not need a frontier model. The model is not there to recalculate the analytics. It is there to orchestrate the tools, inspect what happened, apply a few explicit decisions and leave a report that explains its own gaps. The analytics job has a narrow example of recovery already baked into its instructions. A sandboxed DNS or Keychain failure should be retried with the correct local permissions before the provider is declared broken. After that, every provider still gets its own state. The job can respond to a known operational wrinkle without hiding a genuine failure behind a confident summary. That is much more limited than saying the pipeline fixes itself. Local scheduled jobs can miss their time when the Mac is asleep or offline. Providers change, credentials expire and prompts can still be wrong. The useful bit is that some recovery can be expressed at the same level as the job, and you can inspect everything afterwards. If a cheap model can wrap reliable code, handle a known failure path and occasionally surface something the fixed report would miss, why wouldn't I use it? ## The artefact is part of the automation I like that these reports can be made for one person. They do not need to expose every option that a general analytics or research product needs. I can choose the comparisons, density, graphs, source notes and access path that make the information useful to me. That makes the HTML artefact part of the system rather than a decorative export at the end. The scheduled job keeps it current, the deterministic pieces keep the important facts stable, and the model has room to help where fixed code becomes awkward. I have not changed my mind into thinking every scheduled task needs an LLM. A plain scheduler and script are still the right answer for plenty of jobs. This is just a nice way to combine those tools when the report also needs consolidation, bounded judgement and a personal view.