But it does not exist today. Maybe it is because people don’t want it enough?
Speaking for myself, I want cheap cron badly but I’m not sure I’m ready to trust a “public” canister that I send cycles to and that invokes my canister on a periodic basis. That canister would need to be autonomous, which very few people have done so far (and for good reason, since the source code needs to be open, airtight, and preferably audited).
I can see it happening in the future, but I need cheap heartbeat right now. I could build such a public canister, but there’s no guarantee that enough people will choose to use it for the time spent to be worth it. I might as well spend an hour setting up a cronjob on AWS that calls my canister.
(I know this sounds like I’m making excuses, but I want to be brutally honest on the thought process that’s going through my head.)
What I’m curious about is how much work it would take for the replica to support configurable heartbeat intervals or even an inspect_message for heartbeats. Is it a lot of work? Even something simple like a canister exposing some simple integer heartbeat_interval configuration variable that tells the replica how often to call its heartbeat (with the unit being # of blocks) would go a very long way, I think.
EDIT: Here is a reason why inter-canister calls may not be the safest choice right now. Another reason why we may not be ready for a public cron canister just yet.