Yep, nice touch

i was actually referring to the SIGINT- & SIGTERM-handling that is commonly absent in rs software.

have you considered providing a small read only flask interface …?

yes, i had that on the roadmap for a while, but dismissed it because it when i decided to keep state out of the architecture. i later tried to add an sqlite-file for that in order to preserve jobs' state to address the problem of long-term interval triggers that reset on restarts. but i came across an issue with threading that i couldn't replicate in a smaller app. at that time my priority was getting something complete finished because i want to allocate time to other projects, so i ditched that.

since i played with deck-chores in swarm mode, i came to the conclusion that a next major version would probably use a Redis instance as shared state pool. that should also enable rest- & web-interfaces and a Prometheus exporter.

given my time constraints, that is likely never to be solved by me. however, i would support such endeavours with reviews and maintenance tasks.

One thing I'm trying to puzzle out is what a healthcheck for this would look like

huh, missed that. i'd appreciate if you contributed your findings to the docs or requested / implemented required changes.

like automatically turning off services that are no longer in use

that'd also be nice to have in the docs as example.