Simplifying the Bindicator with GitHub Actions

The bin day reminder started as a quick solution and grew into a small tangle. It worked, but there were too many moving parts for what should be a simple weekly nudge. The rewrite keeps the useful idea and removes the overhead. The new version runs entirely on GitHub Actions. That change turns an always on service into a file in a repository, and it drops the ongoing burden of keeping another server alive.

Why change something that already worked? Reliability and simplicity were the push. The old setup drifted over time. Little fixes piled up, a dependency updated here, a script patched there, and suddenly the project depended on a small stack that needed care. That is fine for a hobby, until you realise you are doing maintenance instead of solving the small problem you started with. A reminder should be boring. It should fire when needed, be easy to adjust, and not take attention away from other work.

The rewrite starts with a principle. If a job can be done by a hosted scheduler that you do not have to maintain, prefer that over running your own timer. GitHub Actions provides that scheduler for free in a way that fits the rest of the workflow. There is already a repository, there is already version control, and there is already a place to store small secrets. Using Actions means the reminder inherits all of that in a single place.

The new system is a set of small steps described in a workflow file. The file lives at .github/workflows/. The steps are plain and easy to read. They run on a schedule and when triggered by hand. The schedule is the heart of the reminder. When the time arrives, the job runs. The steps do the minimal work needed to decide whether a reminder should be sent today, then they send it. No server, no database, no daemon to watch. If you want to see what happened, you click the workflow run and read the logs.

Moving to Actions changes how updates work. Before, changes meant logging into a host, editing a file, restarting a process, and hoping nothing else broke. Now, updates are a pull request away. You can read the diff, comment on it, and roll back if a change behaves badly. There is also a record of each run with the exact version of the workflow that produced it. That kind of traceability is valuable even for a small tool, because it removes guesswork when something looks off.

There are trade offs. You give up fine grained control over the environment. You accept the limits of the runner and the schedule. In return you gain a clear, predictable system that costs nothing to run and does not live on your hardware. For a weekly reminder, that is a good deal. If you need heavy processing or low latency, you would make a different choice. For this use case, hosted is better.

Another benefit is that the whole thing is portable. The logic is written down in one place. If it needs to move again in the future, the plan is visible in the steps and the comments. It can be recreated elsewhere with minimal effort. That is a nice property for small automations that tend to outlive the particular tools used to build them.

The rewrite also forced a pass over assumptions. The goal is a useful nudge, not a complex model of the world. Keep inputs minimal. Keep the logic readable. Make it easy to test a run without waiting for the real day. Prefer plain text where possible. These rules keep the project from wandering back into cleverness for its own sake.

From an operational point of view, the result is quiet, which is the target. Runs are scheduled. A record appears when they execute. If a change is needed, it is a small edit and a commit. There is nothing to babysit and nothing that will wake you up because a box ran out of disk or a system update broke a dependency. One less service to host is a win.

There is room to extend later if it adds value. You could add a manual trigger for ad hoc checks, a simple notification when the workflow itself fails, or a second schedule for bank holiday adjustments if needed. Those ideas can wait. The important part is that the reminder is useful again without claiming more attention than it deserves.

The short version is that this was a subtraction exercise. Take a working but noisy thing, remove the parts that do not serve the goal, and keep what matters. The result fits into the existing development flow, does not add cost, and is easy to reason about. That is the kind of small win that makes the rest of the system feel lighter.

Thanks for reading. If you have a similar small tool that grew too large, try moving it into a scheduled workflow. It might be all it needs to become low effort again.