Laravel scheduler monitoring

Separate what Laravel is configured to run from what actually ran.

LatidoFlow keeps schedule discovery and execution proof as different facts. A synced command can still be waiting for its first real lifecycle event.

Two layers prevent a false green.

Layer 1

Definition sync

The optional Laravel detector kit can sync named schedules and their timing configuration into LatidoFlow. This confirms that the definition was received; it does not claim that the scheduler invoked it.

Layer 2

Runtime evidence

Lifecycle events record starts, explicit skips, successes, and failures for supported scheduled executions. A missing expected event can then open a missing-run incident.

How scheduler state is interpreted

  1. 1

    Discover a stable schedule identity

    Named schedules can be matched to a monitor without exposing command arguments as a public identity. Unnamed schedules remain waiting definitions until they have a safe name.

  2. 2

    Report the real outcome

    Supported foreground and background executions send lifecycle evidence around the command rather than treating sync as a successful run.

  3. 3

    Distinguish a skip from a disappearance

    An explicit scheduler skip advances the expected window without fabricating a successful run. No event by the allowed deadline remains a missing-run condition.

Current boundaries

Keep exploring

Make one Laravel schedule observable

Start with a named command whose absence would otherwise be discovered through stale data or a customer report.