Scheduled Sling jobs missed during AEM Author pod replacement or topology change

This article describes why scheduled Sling jobs in Adobe Experience Manager (AEM) Author may be missed during pod replacements or topology changes in Kubernetes-based deployments, and provides recommendations to ensure reliable job execution.

Description description

Environment

  • Adobe Experience Manager (AEM) Author, all supported versions
  • Kubernetes-based deployments (AEM as a Cloud Service or on-premises deployments running on Kubernetes)

Issue/Symptoms

  • Scheduled Sling jobs, such as automated email generation or batch processing jobs, do not run at the expected time.
  • The system does not automatically retry missed jobs after the environment stabilizes.
  • Subsequent scheduled jobs resume normal operation.

Cause

Scheduled jobs that use non-persisted scheduling mechanisms, such as Sling Commons Scheduler with Runnable, depend on the lifecycle of a specific AEM Author pod. If Kubernetes terminates or replaces that pod during the scheduled execution window and the cluster topology is still stabilizing, the scheduler might be unavailable and the job can be missed.

The system does not automatically replay missed executions after recovery. Only persisted Sling Jobs that use queue management can guarantee execution across topology changes.

Resolution resolution

Follow these steps to resolve the issue:

  1. If jobs use non-persisted schedulers, such as Sling Commons Scheduler with Runnable, they can be missed during pod replacements or topology changes.

  2. Implement scheduled jobs by using Sling Jobs (JobManager and JobConsumer) with persisted queues so jobs are not lost during pod replacements or topology changes.

    • Configure an ORDERED job queue if only one execution per cluster is required.
    • Design jobs to be idempotent and resumable so retries or catch-up executions do not create duplicate processing.
  3. Add logic that enqueues a job when the last successful run becomes stale or is missed because of downtime. For example, on startup or at regular intervals, check the timestamp of the last successful execution and enqueue a new job if the timestamp is older than expected.

  4. Monitor job queue health and scheduler configurations to detect missed or delayed executions.

  5. Investigate the cause of unplanned pod replacements, such as health check timeouts or maintenance events, and address any underlying infrastructure issues when possible.

  6. After you deploy the changes, monitor scheduled job executions during pod replacements or topology changes to confirm that jobs are no longer missed.

recommendation-more-help
experience-cloud-kcs-help-kbarticles