Mintplex-Labs/anything-llm · warning

Cannot create: maximum of ${activation.limit} active schedul

Error message

Cannot create: maximum of ${activation.limit} active scheduled jobs reached. Disable another job first.

What it means

Capacity error from POST /api/scheduled-jobs. The endpoint counts currently enabled jobs (ScheduledJob.countActive) and rejects creation of a new job — which always starts enabled — when that count has reached ScheduledJob.MAX_ACTIVE; activation.limit in the message echoes the configured cap. In the shipped code MAX_ACTIVE is null (unlimited), so this 400 only fires on deployments where MAX_ACTIVE was set to a positive integer (forks/embedded builds).

Source

Thrown at server/endpoints/scheduledJobs.js:171

          errorMessage = "Schedule is required";
        } else if (!ScheduledJob.isValidCron(schedule)) {
          errorMessage = "Invalid cron expression";
        } else if (tools?.length > 0 && !Array.isArray(tools)) {
          errorMessage = "Tools must be an array";
        }
        if (errorMessage)
          return response.status(400).json({
            job: null,
            error: errorMessage,
          });

        // New jobs default to enabled, so creating one always counts as an
        // activation. Reject if it would push us past the configured cap.
        const activation = await ScheduledJob.canActivate();
        if (!activation.allowed) {
          return response.status(400).json({
            job: null,
            error: `Cannot create: maximum of ${activation.limit} active scheduled jobs reached. Disable another job first.`,
          });
        }

        const { job, error } = await ScheduledJob.create({
          name: name.trim(),
          prompt: prompt.trim(),
          tools: tools || null,
          schedule: schedule.trim(),
        });

        if (error) {
          return response.status(400).json({ job: null, error });
        }

        backgroundService.addScheduledJob(job);
        Telemetry.sendTelemetry("scheduled_job_created").catch(() => {});
        return response.status(201).json({ job, error: null });
      } catch (e) {

View on GitHub (pinned to 3aec848f28)

Solutions

  1. Disable or delete an existing enabled job first (PUT /api/scheduled-jobs/:id with {"enabled":false}, or DELETE), then retry the create
  2. Audit enabled jobs with GET /api/scheduled-jobs and prune ones you no longer need
  3. If the cap is wrong for your deployment, adjust ScheduledJob.MAX_ACTIVE in server/models/scheduledJob.js — there is no env/config option yet (marked @todo)

Example fix

// before — create while at the cap
await api.post('/scheduled-jobs', newJob); // 400 max active reached

// after — free a slot, then create
await api.put(`/scheduled-jobs/${staleJobId}`, { enabled: false });
await api.post('/scheduled-jobs', newJob);
Defensive patterns

Strategy: validation

Validate before calling

// Count enabled jobs before creating a new one
const { jobs } = await api.get('/scheduled-jobs');
const enabledCount = jobs.filter(j => j.enabled).length;
if (MAX_ACTIVE !== null && enabledCount >= MAX_ACTIVE) {
  await api.put(`/scheduled-jobs/${pickDisposable(jobs).id}`, { enabled: false });
}
await api.post('/scheduled-jobs', newJob);

Prevention

When it happens

Trigger: POST /api/scheduled-jobs while the number of jobs with enabled=true already equals MAX_ACTIVE. Every create counts as an activation because new jobs default to enabled, so the cap is hit one create earlier than a total-job count would suggest.

Common situations: Automation or agent-skill flows that mint scheduled jobs on every invocation without disabling old ones; test scripts creating many jobs; forking AnythingLLM and setting MAX_ACTIVE to bound scheduler load.

Related errors


AI-assisted analysis of Mintplex-Labs/anything-llm@3aec848f28 (2026-08-18). Data as JSON: /api/errors/9fc3e83899bfe3a8. Report an issue: GitHub.