Skip to documentation

Migrate without losing coverage

Use a new monitor key only when you intentionally want separate history. Reusing the existing key keeps incident and execution continuity.

Manual pings to a framework integration

  1. Install the matching Hangfire, Quartz.NET, Celery, or Laravel package.
  2. Configure it with the same application key as the manual monitor.
  3. Ensure the discovered recurring-job key matches the existing manual key, using the integration's override attribute or decorator when necessary.
  4. Deploy and confirm reconciliation plus one terminal run.
  5. Remove the old manual heartbeat or wrapper only after the framework lifecycle is visible.

Never run both paths indefinitely: duplicate terminal events make execution history ambiguous.

Completion-only heartbeats to lifecycle tracking

  1. Keep the same monitor key and schedule.
  2. Replace the final heartbeat with the SDK wrapper, or add start plus exactly one complete or fail terminal event.
  3. Re-throw the original job exception after recording failure.
  4. Verify one successful and one controlled failed execution.

The schedule and history remain attached to the existing monitor. Lifecycle tracking adds duration and stuck-run evidence.

Deprecated framework entrypoints

  • Hangfire: replace configuration.MonitorAll() with builder.Services.AddCronRadarHangfire() after Hangfire storage and server registration. The canonical Hangfire guide documents retry-aware failure behavior.
  • Quartz.NET: await scheduler.MonitorAll(apiKey) after the scheduler and recurring triggers are configured. Replace deprecated synchronous calls before removing the old package version.
  • Celery: use setup_cronradar(app) once on the Celery application. Remove older selective/all mode flags; all periodic tasks are monitored unless decorated with @skip_monitor.

Move an API key between environments

Do not copy the production key. Create a CronRadar application for the destination environment, create a new key, update its secret store, deploy, and verify. After the destination reports a real run, revoke any key that no longer has a deployed consumer.

Move from another heartbeat service

Run both services for one normal schedule window. Register CronRadar with the same five-field schedule, verify a real success and notification drill, then remove the old heartbeat. Avoid changing the scheduler and monitoring provider in the same deployment; keeping the scheduler stable makes rollback and diagnosis straightforward.