Introduction

If multiple identical NestJS Pods run the same scheduled task in Kubernetes, every instance will trigger the job unless you coordinate them explicitly. A local in-memory flag is not enough because each Pod has its own memory space. To prevent parallel execution, you need a distributed lock or you need to move the scheduling responsibility out of the application layer entirely.

Why the Problem Happens

@nestjs/schedule runs inside each application process. If you deploy three replicas, each one evaluates the cron expression independently.

Simple scheduled job:

1import { Injectable } from "@nestjs/common";
2import { Cron } from "@nestjs/schedule";
3
4@Injectable()
5export class ReportJob {
6  @Cron("0 * * * * *")
7  handleCron() {
8    console.log("job started");
9  }
10}

With multiple Pods, that code runs once per Pod. Kubernetes does not automatically deduplicate in-process cron jobs.

Do Not Rely on In-Memory Guards

This does not solve the problem in Kubernetes:

private running = false;

It only prevents overlap inside one process. Another Pod knows nothing about that flag.

If the job must be singleton across replicas, the lock must live in shared infrastructure such as Redis, Postgres, or another coordination system.

Redis Lock Example

A common approach is a short-lived distributed lock in Redis.

1import { Injectable, Logger } from "@nestjs/common";
2import { Cron } from "@nestjs/schedule";
3import Redis from "ioredis";
4
5@Injectable()
6export class ReportJob {
7  private readonly logger = new Logger(ReportJob.name);
8  private readonly redis = new Redis(process.env.REDIS_URL!);
9
10  @Cron("0 * * * * *")
11  async handleCron() {
12    const lockKey = "locks:report-job";
13    const lockValue = `${process.pid}-${Date.now()}`;
14
15    const acquired = await this.redis.set(lockKey, lockValue, "NX", "PX", 55_000);
16    if (!acquired) {
17      this.logger.log("Skipped: lock already held");
18      return;
19    }
20
21    try {
22      this.logger.log("Running job");
23      await this.runJob();
24    } finally {
25      const current = await this.redis.get(lockKey);
26      if (current === lockValue) {
27        await this.redis.del(lockKey);
28      }
29    }
30  }
31
32  private async runJob() {
33    await new Promise(resolve => setTimeout(resolve, 2000));
34  }
35}

The NX option means “only set if absent.” That turns Redis into a simple lock coordinator.

Use a Lock Expiration

Every distributed lock needs a timeout or lease. If a Pod crashes while holding the lock, the lock must eventually expire or the job will stop forever.

That is why the Redis example uses a TTL. Set the TTL long enough to cover normal execution time, but not so long that crash recovery becomes slow.

If the job duration can exceed the TTL, implement lock renewal or use a more robust coordination approach.

Database Lock Alternative

If you already depend on Postgres, an advisory lock can be a good fit.

1const result = await this.dataSource.query(
2  "SELECT pg_try_advisory_lock($1) AS locked",
3  [12345]
4);
5
6if (!result[0].locked) {
7  return;
8}

That avoids introducing Redis only for locking. The tradeoff is tying the scheduling coordination to database availability and transaction behavior.

Sometimes the Right Answer Is Kubernetes CronJob

If the task is truly scheduled infrastructure work and does not need to live inside the web service process, Kubernetes CronJob is often cleaner than NestJS in-process scheduling.

Benefits:

• single scheduling authority
• no distributed lock logic in app code
• retries and history handled by Kubernetes

NestJS scheduling is convenient, but not always the best abstraction for singleton cluster-wide jobs.

Make the Job Idempotent Anyway

Even with locks, jobs should be written so duplicate execution is not catastrophic. Locks reduce the probability of overlap; idempotency reduces the damage if overlap still happens because of clock drift, TTL expiry, or split-brain style issues.

Examples of idempotency:

• upsert instead of blind insert
• mark processed rows with stable identifiers
• skip already-completed work

This is distributed-systems hygiene, not optional polish.

Common Pitfalls

The biggest mistake is using an in-memory boolean and assuming it prevents overlap across Pods. It does not.

Another issue is acquiring a distributed lock without a TTL. If the worker crashes, the lock can become permanent.

Teams also sometimes choose app-level scheduling when Kubernetes CronJob would be operationally simpler and clearer.

Summary

• NestJS scheduled jobs run in every replica unless you coordinate them.
• In-memory guards only work inside one process, not across Pods.
• Use a distributed lock such as Redis or database advisory locking for singleton execution.
• Always give the lock a TTL or lease strategy.
• Prefer Kubernetes CronJob when the job is cluster-level infrastructure work rather than app-local behavior.