Scheduler Laravel Package

Product Decisions This Supports

• Build vs. buy for scheduling UX. The core product question this package forces is whether scheduled/background work should be code-defined (deploy to change) or data-defined (editable at runtime by an operator). Netflex Scheduler is the data-defined pattern: schedules live in storage, a single system cron entry dispatches them, and the schedule table becomes something a UI can manage. If your roadmap includes "let admins/customers set their own recurring jobs," this package is a reference implementation of that model — and a signal of what to build if you don't adopt it.
• Feature scope: schedule management as a product surface. Adoption unlocks a concrete feature set — list/create/pause/edit/delete recurring jobs, per-job intervals, run history — without designing the persistence and dispatch layer from scratch. That's a roadmap line item you can scope in days rather than a sprint.
• Multi-tenant and per-project automation. The DB-backed model maps naturally onto per-tenant schedules (each customer/project owns its own cron entries) rather than a global crontab file. Relevant if your product strategy moves toward customer-configurable automation, integrations sync, or recurring report generation.
• Operational decisions. Where do schedules live, who can change them, and what's the audit story? A DB-backed scheduler makes "who changed this cron and when" a queryable question instead of a code-review question — a meaningful ops and compliance lever.
• Non-decision: it does not inform language/stack or framework choice. It's a component, not a platform bet.

When to Consider This Package

Consider it if:

• You are already on (or deliberately aligning with) the Netflex framework — this is a read-only subtree split of netflex/framework, not an independent library. Its natural home is inside that ecosystem.
• You need runtime-editable schedules: operators or tenants change recurrence without a deployment.
• You want the single-cron-entry dispatch pattern rather than N crontab lines.
• Your team is willing to read the parent framework's source, because that is where issues, history, and design rationale live.
• You're evaluating patterns as much as code — reading it as a worked example is legitimate even if you never install it.

Look elsewhere if:

• You are a standalone Laravel app. Laravel's native scheduler plus a mature package (e.g. spatie/laravel-schedule-monitor for observability) covers most needs with a real support community. Buying into a 0-star, 0-dependent component for core infrastructure is a poor risk trade.
• You need independent maintenance signals. Zero stars and zero dependents mean no external validation, no third-party bug reports, and no ecosystem of answers. A read-only split also means no standalone issue tracker or release cadence you control.
• Scheduling is business-critical and needs SLAs. If missed jobs mean revenue or compliance exposure, you want active maintainers, or a managed/queue-based orchestrator (cloud scheduler, Temporal-style workflow engine, or queue-driven workers) rather than a cron dispatcher.
• You need distributed/HA execution, exactly-once semantics, or deep run observability out of the box.
• Your org cannot absorb vendor/supply-chain risk from an unpinned, low-visibility dependency in a critical path.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version: We evaluated a component for letting schedules be managed as data rather than hardcoded in deployments. The capability is worth having: it turns "recurring jobs" from an engineering chore into a self-service product feature, and it makes schedule changes auditable rather than buried in code review. The specific package is not a strategic dependency — it's an extracted internal component of another vendor's framework, with no independent user base and no standalone support channel. Recommendation: treat it as a design reference and a candidate only if we are already committed to that framework; otherwise fund a small build on Laravel's native scheduler, which we control and can staff.

For engineering — the summary: netflex/scheduler is a read-only subtree split of netflex/framework. It implements the DB-persisted, single-cron-entry dispatch model: a * * * * * system cron invokes the scheduler, which reads due entries from storage and dispatches them. Strengths: the pattern is sound and the tenancy story is clean. Risks: no independent issue tracker (bugs go upstream to the parent repo), no semver contract of its own, no external dependents to validate against, and unknown internal coupling to the parent framework. If we adopt, pin the version, wrap it behind our own scheduling interface so we can swap the implementation, and budget for reading parent-repo source when something breaks. If we don't adopt, replicate the pattern — table of schedules, a due_at-style query, a single cron entry, and a run-log table — which is a contained piece of work and leaves us owning the code.