Do not index
Do not index
At my boutique software studio, I manage 10+ software products with a team of 2 people (myself plus a VA) and hundreds of scripts.
Nowadays, these scripts could also be AI agents, but I’ve been doing this for more than 10 years now, and AI wasn’t a thing back when I started. So, specifically I’m talking about cron jobs.
A cron job is a scheduled task or command in Unix-like operating systems (such as Linux) that runs automatically at specified times or intervals. most of the times, in my case, that means I can call a php script that does something at a specific interval (like every minute, every hour, every day, every 2 months, you get the point)..
Over time, I’ve grown to now having an army of these scripts that run for me 24/7 across all departments of my business.
The beauty of having this kind of setup is that, unlike humans, these scripts can only either complete the job they are designed to do - or not. No drama. States can’t be half-pregnant.
So, for the longest time I was thinking of them as outputting boolean values. Then, it occurred to me that it’s better to treat them as state machines.
What’s a state machine, you may ask.
A state machine is a computational model used to design systems that can be in one of several predefined states at any given time. The system can transition from one state to another based on certain inputs or events.
The best way to describe a state machine I’ve found is describing a stop light.
A stoplight only has 3 states:
- Red: The stoplight is red, meaning vehicles must stop.
- Yellow: The stoplight is yellow, meaning vehicles should prepare to stop.
- Green: The stoplight is green, meaning vehicles can go.
Transitions:
- Red to Green: The stoplight transitions from red to green after a predefined time (e.g., 60 seconds).
- Green to Yellow: The stoplight transitions from green to yellow after a predefined time (e.g., 45 seconds).
- Yellow to Red: The stoplight transitions from yellow to red after a predefined time (e.g., 5 seconds).
Events:
- Timer Event: The system operates on a timer. When a timer expires, the state machine moves to the next state.
- Pedestrian Request (optional): In some traffic systems, a pedestrian button could cause the light to change based on a request, triggering a transition at an appropriate moment.
So, if I were to describe a stoplight as a state machine I would draw the following:
This diagram represents a simple state machine that could model the behavior of a stoplight system when certain conditions are met. In our case, t (time) passes.
States:
- q0: This represents the initial state, where the stop light is likely off.
- q1: This represents the "Red" light, where vehicles must stop.
- q2: This represents the "Yellow" light, where vehicles should prepare to stop.
- q3: This represents the "Green" light, where vehicles are allowed to go.
Similarly, this diagram can describe the state machine system for a cron job.
States:
- OK: This state represents a successful execution of the cron job. The cron job has run as expected, and everything is functioning well. It’s also the likely initial state as when I add a new cron job, I usually make sure it’s working.
- warning: This state indicates that the cron job has not completed its job at the expected time but it is still in time to recover.
- error: This state indicates that the cron job has not completed its job at the expected time (likely due to a failure during the execution of the cron job). It shows that something went wrong, and intervention may be required.
Transitions:
Each transition in the diagram occurs after a specific event (or time interval) — this represents the timer or scheduled trigger that causes the cron job to execute. The system keeps running periodically based on the schedule and may move through these states based on the outcome of each execution.
Run Event:
The Run Event state represents the actual execution of the cron job. After the cron job runs, it transitions to one of the three states: OK, Warning, or Error, depending on the result.
The run event is controlled by a configuration file called the crontab (cron table), where the user can specify when and how often each cron job should run. Each entry in the crontab defines a command to be executed and the schedule for it.
A cron job's schedule is represented by a line containing five time and date fields followed by the command to run:
* * * * * /path/to/script
| | | | |
| | | | +---- Day of the week (0 - 7) (Sunday = 0 or 7)
| | | +------ Month (1 - 12)
| | +-------- Day of the month (1 - 31)
| +---------- Hour (0 - 23)
+------------ Minute (0 - 59)Example Flow:
- The cron job runs and checks its tasks (run event).
- If the task completes successfully, it transitions to the OK state.
- If there’s an issue but the job runs partially (such as a minor delay), it moves to the Warning state.
- If an error occurs (for example, a failed connection or script crash), it moves to the Error state.
- The cron job then continues its cycle, triggering again at the next scheduled time.
As a more tangible example, here are some of the cron jobs that run for one of my SaaS called Treendly, where we spot rising trends in different industries and countries.
Each cron job has a different objective wether it’s to curate topics, sending a newsletter, enriching the trends with search volume info, or getting usernames of the new users, etc.
When designing a new cron job, I think it’s important to keep in mind some of the features that Donella Meadows describes in her book, Thinking in Systems: A Prime - specifically, the system boundaries, feedback loops, and the system behavior over time.
- System boundaries: each cron job should have a clear objective. If you are a JTBD enthusiast like I am, you can think of it as a 1:1 relationship where 1 cron job only has 1 job to be done. Also, cron jobs should be as light as possible in terms of dependencies. Understand what inputs, outputs, and dependencies fall within the scope of the job. This will help avoid unintended consequences or overlooking critical interactions with other systems.
- Feedback loops: we can ensure the cron job has mechanisms to correct its behavior when things go wrong, such as retrying a failed task or sending alerts when a warning state is detected. I implemented a basic observability system so that cron jobs communicate their state to me at all times. I’ve developed my own solution, but if you don’t have time Cronitor is the best paid software I’ve tested for this.
- System behaviour over time: we can anticipate how the cron job will perform under different conditions, such as varying loads or network latencies, and design it to adapt or scale as needed. This approach helps ensure that the cron job remains resilient and sustainable in the long run, contributing to the overall health of the system.
As you can see in the image above, I also color coded each state, just like we have seen in the stoplight example. Red means “problem”, yellow means “we might have a problem”, green means “don’t worry about it”.
One of the advantages of having a state machine like this is that cron jobs now compete for my attention. I can clearly see from the image above that I need to put my attention towards the cron job called “Curate topics” because it’s the only one that’s red.
Understanding different business layers with state machines
Treating individual scripts managed by a crontab scheduler as a state machine is only the first and most low level layer in how I run my business . A key insight for me was that the same approach can be scaled up to understand individual products and the business as a whole.
We can identify three layers:
- Cron job level
- KPIs level
- Individual product level
- Business level
Cron jobs make up a KPI. Multiple KPIs make up a product. Multiple products make up the business itself.
We’ve already seen how the state machine is behaving on the cron job level.
At the KPIs level, different KPIs are monitored and updated at recurring intervals and each one has a state. Here I’m using a green happy face to indicate that everything is good, a grey meh face indicating that things might are steady but could be better and a red sad face indicating things are not looking good.
In the following image we can see all the KPIs related to a certain product. At a glance, I can clearly understand that we are not growing as much as we can even if revenue is going up, and that we need to work more on shipping a major roadmap milestone for this product.
(please note: some information regarding products or KPIs is and will be redacted from the images for privacy reasons)
Similarly, at the product level, each individual SaaS product I own has an health indicator which indicates the state that the product it’s in.
Finally, at the business level, the whole business has the same indicator to help me understand the current state.
Your life as a state machine
I do not set clear boundaries between my business and life, because my business is there to help me live my best life in the first place.
That’s why I thought to use the same approach in my life as well. As a big believer in quantified self, this was actually very easy to do.
Here’s a dashboard where I track exactly how much time I spend in each area of my life. Each day is then assigned a state automatically.
In the end, life has layers as well, so I can understand not only how my days are going but also how my weeks and years are going. By doing so, it’s easy to implement feedback loops on the state machine of your life and spot patterns that can help you live better.
For example, by tracking how much time I spend on different activities each day — work, padel, leisure, and personal projects, I can spot when I'm overloading myself with work and neglecting self-care. If I notice that my "leisure" time is consistently low, I can set up a feedback loop to prioritize more downtime, ensuring I stay balanced.
—
In conclusion, by viewing both business processes and personal life through the lens of state machines, I’ve been able to build a more resilient, adaptable system.
The beauty of this approach lies in its simplicity and clarity: each state is well-defined, feedback loops keep things in check, and transitions are clear. This method not only keeps my business running smoothly but also allows me to monitor and adjust my personal life, making it easier to spot patterns, make informed decisions, and continuously improve.
Whether it's automating cron jobs or tracking my sleep, state machines help create a framework that can scale and evolve, giving me more control over both my work and personal growth.
In the end, treating everything as a system makes it easier to thrive in an ever-changing environment.
