[HN Gopher] Show HN: FastScheduler - Decorator-first Python task...
___________________________________________________________________
Show HN: FastScheduler - Decorator-first Python task scheduler,
async support
Hi! I've built this because I kept reaching for Celery for simple
scheduled tasks and it felt like overkill. I just needed "run this
function every hour" or "daily at 9am", not distributed workers.
So it's decorators for scheduling (@scheduler.every(5).minutes,
@scheduler.daily.at("09:00")), state saves to JSON so jobs survive
restarts, and there's an optional FastAPI dashboard if you want to
see what's running. No Redis, no message broker, runs in-process
with your app. Trade-off is it's single process only -- if you need
distributed workers, stick with Celery.
Author : michielme
Score : 39 points
Date : 2026-01-13 14:45 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| fucalost wrote:
| This looks great OP. Do you have anything on the roadmap that
| you'd be open to receiving PRs for? I noticed there weren't any
| issues in the repo and would be keen to lend a hand!
| michielme wrote:
| Definitely open to PRs! Still early days so lots of room for
| improvement. Feel free to open an issue if you have ideas.
| techjamie wrote:
| This is really cool, and I could see myself using this. Sometimes
| I need functionality like this, but can't be bothered to build up
| the infrastructure around it. This is perfect for that use case.
| michielme wrote:
| Thanks! Yeah that's exactly the use case -- when you just need
| something scheduled without setting up a whole stack.
| antonbassyk wrote:
| Looks interesting. Wondering how this is different from the more
| established https://github.com/agronholm/apscheduler ?
| michielme wrote:
| APScheduler is solid and more mature. Main difference is the
| API -- FastScheduler is decorator-first so you get
| @scheduler.daily.at("09:00") instead of configuring triggers,
| executors, and job stores separately. Also has a built-in
| FastAPI dashboard.
| languagehacker wrote:
| If Celery seems like overkill for your process, and you're really
| just looking to execute basic cron functioanlity, then why not
| just use crontab to invoke your Python script?
|
| I can think of two major ways to operationalize a Python script
| that needs to run continuously. One is with containerization,
| which usually means Kubernetes, which already has a perfectly
| fine resource definition for cronjobs. The other approach is to
| run the script in a bare metal or VM, which would mean defining a
| service to ensure that the process can be managed appropriately,
| restarted if it dies, and the like. In other words, defining a
| service is about just as much effort as defining a cronjob, and
| there's no escape from some amount of "ops work" that isn't
| encapsulated in a Python script.
|
| So why not just use the tried-and-true prior art than worry about
| building and supporting your own secret third thing that others
| would need to learn, support, maintain, and keep in mind when
| debugging a problem?
| bityard wrote:
| I would deploy this today to run my backups if jobs could be
| defined in the UI as well.
___________________________________________________________________
(page generated 2026-01-13 23:01 UTC)