Bhavana's Week 09: A Standing Instruction
Week nine of an SEO engineer's fellowship report shows how a cron schedule, timed 30 minutes after a dependent scrape, turns a manual script into a standing instruction.
A script that no one runs does nothing. That's the problem Bhavana Bhariday, a Humanitarians AI Fellow working as the SEO engineer on a job-listings project, set out to fix in week nine of her report: not building a new feature, but making sure the features already built actually run on their own.
Cron as a standing instruction
The core idea is simple once it's stated plainly. Instead of a person checking a clock and running a script by hand, a cron schedule is a standing instruction: run this automatically, at these times, forever. Nobody has to remember, and nobody has to be awake for it to happen. Bhavana set up a GitHub Actions workflow with a schedule line in cron syntax to run the job's submitter four times a day, alongside a manual workflow_dispatch trigger so the same automation could be fired on demand for testing instead of waiting for the next scheduled slot.
Why the timing had to be staggered
The interesting part isn't that the job runs on a schedule, it's when. Submissions run about 30 minutes after each scrape cycle finishes, so there's always freshly scraped data waiting by the time the submitter runs. Flip that order, run the submitter before the scraper, and you'd be querying for jobs that don't exist yet. The stagger is the whole point: a dependent job has to run after the thing it depends on, not just on its own convenient schedule.
Documenting how the pieces fit together
Alongside the cron work, Bhavana started an architecture document. Nine weeks into the project, there are five features in place: JSON-LD structured data, sitemaps, landing pages, the Google indexing API integration, and now the cron automation. Each one makes sense read in isolation, but what triggers what, and what depends on what, is invisible if you're reading five separate files. The architecture doc is what turns five individual features into one legible system that someone else could actually understand.
Key takeaways
- A cron schedule turns a manually run script into an automation that fires on its own, without anyone remembering to trigger it.
- A workflow_dispatch manual trigger lets you fire the same job on demand for testing, without waiting for the next scheduled run.
- Stagger dependent jobs deliberately: this project runs its submitter about 30 minutes after each scrape cycle finishes, so fresh data is always ready.
- Get the order wrong and a dependent job will query for data that hasn't been scraped yet.
- An architecture document is what turns a set of individually shipped features into one system other people can reason about.
Try it yourself
If you have a script you still run by hand, the exercise here is to ask an AI assistant to turn it into a standing instruction: a cron schedule with a manual trigger alongside for testing. Then ask the harder question: what does that script depend on, and does your schedule actually run it after that dependency, not before? This kind of practical, ship-it engineering work is what Humanitarians AI Fellows take on as part of their fellowship projects.
Chapters
Full transcript(auto-generated, with timestamps)
Cron: Making Scripts Run Automatically
[0:00]Hi, I'm Bhavana, a humanitarian's AI fellow, week nine of my job seeker report, where I'm the SEO engineer making Google find and rank our job listings. A script that no one runs does nothing. So, this week I set the fast indexing system to run itself on a schedule and started documenting how the whole system fits together. The idea is simple once you say it plainly. Instead of a person checking a clock and running a script by hand, a cron schedule is a standing instruction. Run this automatically at
Staggering Workflows for Fresh Data
[0:32]These times forever. Nobody has to remember. Nobody has to be awake. The automation just happens on the same rhythm as the data it depends on. Here's the whole instruction. A schedule line in cron syntax run four times a day. A manual trigger workflow dispatch riding alongside, so the same automation can be fired on demand for testing instead of
Manual Triggers and Architecture Documentation
[0:56]Waiting for the next slot. And the steps, run the submitter, then report removals. That's the automation top to bottom. The timing wasn't arbitrary. Submissions run about 30 minutes after each scrape cycle finishes, so there's always freshly scraped data waiting when the submitter runs. Flip the order, submitter first, scraper second, and you'd be querying for jobs that don't exist yet. The stagger is the whole point. The dependent job runs after the thing it depends on. The second thread is
Recap: Wiring Features into a System
[1:26]Quieter, but it matters. Nine weeks in, there are five features. JSON LD, site maps, landing pages, the indexing API, and now this cron. Each makes sense on its own, but what triggers what? What depends on what? That's invisible if you're reading five separate files. So, work started on an architecture doc. It's what turns five features into one legible system. The recap. A script that no one runs does
Your Turn: Stop Being the Cron Job
[1:52]Nothing, so cron became the standing instruction. Run the submitter four times a day, automatically, forever. The timing is staggered 30 minutes after each scrape, so the dependent job always runs after the data it needs. A manual trigger rides alongside for testing. And the architecture doc began turning five separate features into one legible system. The rule this week, shipping a piece isn't the same as wiring it into a system. Your turn. Find a script you still run by hand and ask Claude to turn it into a standing instruction, a cron schedule with a manual trigger alongside for testing. Then ask the harder question. What does it depend on? And does your schedule actually run it after that thing, not before? Run this and stop being the cron job, a standing instruction.
