Dkron is a production-grade, distributed cron and job scheduling system written in Go. It runs as a cluster of nodes coordinated via HashiCorp Raft for consensus and Serf for membership, providing fault tolerance and automatic leader election. The system exposes a REST API, a gRPC API, and an embedded React admin UI. Jobs are executed through a plugin architecture supporting multiple executors (shell, HTTP, Kafka, NATS, RabbitMQ, Google Cloud Pub/Sub, gRPC) and processors (log, file, syslog, Fluentd). The scheduler extends standard cron syntax with custom descriptors like @at, @after, and @manually, and supports retries, concurrency control, job chaining, and notifications via email/webhook. State is persisted in embedded BuntDB for application data and BoltDB for the Raft log, with optional cloud auto-join via go-discover. The project also includes a commercial Pro tier (ACL, encryption, failover) referenced in the codebase, but the core open-source code is fully functional and well-tested with unit, integration, and end-to-end tests.
Whenever is a Ruby gem and CLI tool that compiles a Ruby DSL into cron syntax and manages installation into the system crontab. In production it converts a project's config/schedule.rb into crontab entries: `whenever` prints generated cron, `whenever --update-crontab` inserts or replaces a marked block non-destructively, and `--clear-crontab` removes it. The DSL supports frequencies (`every 3.hours`), `at` times, raw cron strings, custom `job_type` templates, `MAILTO` settings, output redirection, role filtering for Capistrano, per-job descriptions, and chained job sequences. Architecturally it is a small library with two CLI entry points (`bin/whenever`, `bin/wheneverize`) and optional Capistrano v2/v3 integrations. The core flow reads config/schedule.rb and instance_eval's it inside `Whenever::JobList` (preceded by `lib/whenever/setup.rb` defaults), builds `Whenever::Job` objects, then renders cron lines through `Whenever::Output::Cron`. `Whenever::CommandLine` handles merging with the existing crontab by matching generated `# Begin Whenever...` / `# End Whenever...` blocks. The only hard runtime dependency is `chronic`; ActiveSupport support is optional and tested through an Appraisal matrix. The codebase is compact, readable, and unusually well tested: Minitest/Mocha tests cover unit behavior and functional output across Ruby 2.4-4.0 and ActiveSupport 5.0-8.1. It is a good reference for building cron-generating DSLs or shell-command template engines. Minor rough edges exist—`Numeric` is monkeypatched globally to provide `1.day` style helpers, and a couple of internal APIs have string/symbol option inconsistencies—but these do not undermine its usefulness.
django-celery-beat is a Django library that provides a database-backed scheduler for Celery Beat, allowing periodic task schedules to be stored and managed in a Django database. It offers models for interval, crontab, solar, and clocked schedules, with a full Django admin interface for CRUD operations. The core scheduler (`DatabaseScheduler`) reads enabled periodic tasks from the database and manages their execution, with change detection via a dedicated `PeriodicTasks` model. The codebase is production-stable, well-tested, and actively maintained, supporting recent Django (6.1) and Python (3.14) versions.
Agenda is a light-weight job scheduling library for Node.js with a pluggable backend architecture. The core library provides scheduling (cron, human-readable intervals, debounce), concurrency control, distributed locking, retries with composable backoff strategies, unique job constraints, and persistent job logging. It supports three official backends (MongoDB, PostgreSQL, Redis) via clean abstractions (JobRepository, NotificationChannel, JobLogger) that can be mixed and matched. The monorepo also includes two companion applications: agendash (a Vue 3 web dashboard for monitoring and managing jobs with real-time SSE updates) and agenda-rest (a Koa-based REST API server with CLI entry point). The codebase is fully TypeScript, ESM-only (v6), uses pnpm workspaces, changesets for versioning, Vitest for testing, and has extensive shared test suites that ensure backend interoperability. The architecture demonstrates strong separation of concerns, but there is some code duplication across backends and legacy v4 documentation that could cause confusion.
Sidequest.js is a Redis-free background job processing system for Node.js/TypeScript that provides distributed, durable job processing using existing databases (PostgreSQL, MySQL, SQLite, MongoDB). The system features a modular monorepo architecture with separate packages for core logic, engine, database backends, web dashboard, and CLI tools. It implements job lifecycle management, scheduling via cron expressions, uniqueness constraints, retry mechanisms with backoff strategies, and provides a web interface for monitoring and management. The architecture follows clean separation of concerns with dependency injection, worker thread isolation via Piscina, and process isolation through forked child processes. Key entry points include the main Sidequest facade, engine configuration, dashboard interface, and CLI administration tools.
ecschedule is a production-grade CLI tool for managing AWS EventBridge scheduled tasks that trigger ECS tasks. Written in Go, it uses declarative YAML/JSON/Jsonnet configuration files with template functions for environment variables, tfstate lookups, and SSM parameters. The tool supports full lifecycle management: dumping existing rules, diffing local vs remote state, applying changes (create/update/delete), and manually triggering rules. It provides parallel execution for performance, unified diff output with color control, and a plugin system for tfstate and ssm integrations. The codebase demonstrates strong engineering practices: clean separation of concerns, comprehensive unit tests, CI/CD pipelines, and dependency management with dependabot. The architecture is a single-binary CLI with subcommands, leveraging AWS SDK v2 and a custom template engine that defers variable resolution for idempotent diffing. Notable design patterns include a generic parallel job executor with panic recovery and context cancellation, a 'localYAMLForDiff' normalization technique to avoid flapping diffs, and a Resource Groups search-based orphan rule detection using custom tags.
XXL-JOB is a distributed task scheduling framework designed for rapid development, simplicity, and lightweight operation. It consists of a scheduler center (admin) and multiple executors. The admin provides a web UI for CRUD job management, scheduling (cron, fix rate, fix delay), routing strategies (first, last, round, random, consistent hash, LFU, LRU, failover, busyover, sharding broadcast), misfire handling, alarm (email), and monitoring. Executors run on any JVM and communicate with the admin via Netty-based HTTP RPC. The framework supports BEAN (annotated methods), GLUE (online Groovy/script editing), script tasks (Shell, Python, PHP, NodeJS, PowerShell), HTTP tasks, and AI tasks (Ollama, Dify, OpenClaw). It includes an OpenAPI for cross-language integration, user management with role-based permissions, and Docker deployment. The architecture is modular: xxl-job-core provides the executor runtime and shared interfaces, xxl-job-admin is the Spring Boot admin application, and sample executors demonstrate integration. External dependencies include MySQL (persistence), Netty (executor server), Groovy (glue tasks), and Spring Boot. The framework is production-ready with HA support for both scheduler and executor clusters.
sidekiq-cron is a Ruby gem that adds recurring job scheduling to Sidekiq via cron expressions or natural language. It runs a poller thread alongside Sidekiq workers that checks Redis every configurable interval (default 30s) to enqueue jobs whose cron time matches. Jobs are stored in Redis hashes, and duplicate enqueuing across multiple Sidekiq processes is prevented using Redis sorted sets. The gem provides a web UI for managing jobs (enqueue, disable, enable, delete) and supports namespacing, ActiveJob integration, GlobalID argument serialization, and configuration of polling intervals, grace periods, and more. It depends on fugit for cron parsing and cronex for human-readable cron descriptions. The architecture is a clean extension of Sidekiq's own scheduler: it prepends into Sidekiq::Launcher and subclasses Sidekiq::Scheduled::Poller. The codebase is well-tested (Minitest + Mocha) and maintained, with CI running against multiple Ruby and Sidekiq versions.
cheek is a pico-sized declarative job scheduler written in Go. It reads a YAML schedule file defining jobs with cron expressions, retries, environment variables, working directories, and event-driven actions (webhooks, job chaining). The single binary provides a CLI (run, trigger, version) and an embedded HTTP server with a web UI for monitoring job execution and logs. Architecture is monolithic: the scheduler loop runs in a goroutine, executing jobs via os/exec with context cancellation for graceful shutdown. Job logs are persisted to SQLite. External dependencies include SQLite, cron parsing (gronx), HTTP routing (httprouter), CLI framework (cobra), config management (viper), and structured logging (zerolog). The codebase is well-tested, with comprehensive unit tests and CI/CD pipelines for cross-platform builds and Docker images.
Apache ShardingSphere ElasticJob is a distributed job scheduling framework providing elastic sharding, failover, misfire handling, and lifecycle management. It is a Java library that can be embedded in applications or used via Spring Boot auto-configuration. The system coordinates jobs across multiple nodes using a registry center (ZooKeeper, etcd, Nacos, or in-memory). It supports multiple job types (simple, dataflow, script, HTTP) and provides RESTful admin APIs, event tracing, and error notification. The architecture is modular with clear SPI-based extensibility for job executors, error handlers, tracing listeners, and registry center providers. The codebase is well-engineered with extensive tests, but retains some legacy integration paths (Spring XML namespace) and tight coupling to ZooKeeper in core modules.
This is a Claude Code plugin that enables scheduling recurring and one-time tasks using native OS schedulers (launchd on macOS, crontab on Linux, Task Scheduler on Windows). Users describe tasks in natural language (e.g., 'every weekday at 9am review yesterday's code'), and the plugin converts that to cron expressions, registers the task with the OS scheduler, and executes `claude -p "prompt"` at the scheduled time. It supports autonomous execution with `--dangerously-skip-permissions`, git worktree isolation for tasks that modify code (creates a branch, runs Claude, commits and pushes changes), and provides commands to list, remove, run, and view logs of scheduled tasks. The architecture is modular: platform-specific scheduler implementations inherit from a base class, cron parsing and humanization are separate utilities, and execution history is stored as JSONL files. The codebase demonstrates strong security awareness with shell escaping, input validation via Zod schemas, and careful handling of user-provided values in generated shell scripts.
MainWP Dashboard is a WordPress plugin that provides a centralized management console for controlling multiple WordPress child sites from a single dashboard. It enables administrators to perform bulk updates, backups, security monitoring, uptime checks, content publishing, user management, and cost tracking across all connected sites. The system is architected as a monolithic WordPress plugin with modular extensions (logs, cost tracker, API backups, system monitor) that each have their own database tables, admin pages, REST endpoints, and cron jobs. Key entry points include the main plugin bootstrap (mainwp.php), AJAX handlers via MainWP_Post_Base_Handler, REST API v2 controllers under /mainwp/v2/, and a new Abilities API (wp-abilities/v1/) for programmable site operations. Data flows involve periodic cron tasks that sync child site status, updates, and health metrics into custom database tables, which are then exposed through dashboard widgets, email notifications, and REST endpoints. External dependencies include the WordPress core, phpseclib for encryption, and various JavaScript libraries (jQuery, Semantic UI, DataTables, ApexCharts, Dropzone, GridStack). The codebase demonstrates professional engineering with extensive test coverage (PHPUnit for abilities, REST, and regression tests), a structured class hierarchy, and security-conscious patterns like nonce verification, capability checks, and credential encryption at rest. However, it also carries legacy complexity from years of development, including large raw SQL queries, singleton overuse, and some deprecated PHP practices.
Tieba-Cloud-Sign is a PHP web application designed to automate the sign-in process for Baidu Tieba forums. It provides a web interface for managing multiple Tieba accounts (via BDUSS cookies) and scheduling automatic sign-in tasks through a built-in cron system. The application features a plugin architecture that allows extending functionality, such as pushing sign-in results to QQ via go-cqhttp or backing up the database to QQ. The core system handles user authentication, Tieba API interactions (including retrieving TBS tokens and performing sign-ins), and provides an administrative interface for configuration. Plugins are integrated via hooks and can add their own settings, cron jobs, and UI components. Data is stored in a MySQL database, with tables for users, account credentials, plugin configurations, and operational logs. Key technical components include a custom WebSocket client for real-time communication with go-cqhttp (used by QQ-related plugins), a SQL dump utility for database backups, and an AJAX-driven settings interface. The frontend relies on Bootstrap 3.3.2 and jQuery for responsive UI elements, including modal dialogs for plugin configuration.