Most workflow failures are not caused by bad code. They happen in the gap between steps: a process dies after a charge succeeds but before the order is confirmed, leaving the system in a state that is difficult to detect and expensive to recover from. Gravtory is built to close that gap. Every step result is checkpointed atomically to the database before the next step begins. On restart, completed steps are loaded from the checkpoint and skipped entirely. The workflow continues from the exact point of failure, with no risk of duplicate execution. The design intentionally avoids introducing new infrastructure. Gravtory runs on the database already present in the stack, whether that is PostgreSQL, MySQL, SQLite, MongoDB, or Redis. Workers coordinate through the database directly. There is no message broker, no separate server, and no managed service to depend on. The engine covers the full operational surface: saga compensation with automatic rollback, parallel fan-out with per-item checkpointing, distributed multi-machine workers, human-in-the-loop approval gates, built-in cron scheduling, OpenTelemetry integration, and native LLM step support with checkpointed AI calls and token tracking. Feedback from engineers who have dealt with this class of problem in production would be particularly valuable, especially on patterns the current design does not yet handle well.

Gravtory

Crash-proof Python workflows. Zero infrastructure.

Crash-proof Python workflows. Zero infrastructure.