Mintplex-Labs/anything-llm · warning

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

Error message

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

What it means

400 from PUT /api/scheduled-jobs/:id. Setting enabled:true is treated as an activation; before updating, the handler calls ScheduledJob.canActivate({excludeId: id}) which counts all *other* enabled jobs and rejects the update when that count has reached ScheduledJob.MAX_ACTIVE. The excludeId prevents a plain re-save of an already-enabled job from double-counting itself.

Source

Thrown at server/endpoints/scheduledJobs.js:250

          if (!ScheduledJob.isValidCron(schedule)) {
            return response
              .status(400)
              .json({ job: null, error: "Invalid cron expression" });
          }
          updates.schedule = String(schedule).trim();
        }

        // If this update would activate the job, enforce the active-jobs cap.
        // We pass excludeId so a re-save of an already-enabled job is not
        // double-counted against the limit.
        if (updates.enabled === true) {
          const activation = await ScheduledJob.canActivate({
            excludeId: Number(request.params.id),
          });
          if (!activation.allowed) {
            return response.status(400).json({
              job: null,
              error: `Cannot enable: maximum of ${activation.limit} active scheduled jobs reached. Disable another job first.`,
            });
          }
        }

        const { job, error } = await ScheduledJob.update(
          Number(request.params.id),
          updates
        );

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

        await backgroundService.syncScheduledJob(job.id);

        return response.status(200).json({ job, error: null });
      } catch (e) {
        console.error(e.message, e);

View on GitHub (pinned to 3aec848f28)

Solutions

1. Disable another enabled job first (or via the same bulk pass, stage disables before enables), then retry the update
2. Keep rarely-used jobs disabled and enable them on demand
3. Raise or clear ScheduledJob.MAX_ACTIVE in server/models/scheduledJob.js if the cap is inappropriate — no env knob exists yet

// Before enabling via PUT, confirm a slot is free
const { jobs } = await api.get('/scheduled-jobs');
const otherEnabled = jobs.filter(j => j.enabled && j.id !== targetId).length;
if (MAX_ACTIVE !== null && otherEnabled >= MAX_ACTIVE) {
  await api.put(`/scheduled-jobs/${pickDisposable(jobs, targetId).id}`, { enabled: false });
}
await api.put(`/scheduled-jobs/${targetId}`, { enabled: true });

When it happens

Trigger: PUT /api/scheduled-jobs/5 with {"enabled":true} while MAX_ACTIVE other jobs are already enabled. Fires even when the same PUT also edits name/prompt/schedule of a disabled job.

Common situations: Bulk scripts that re-enable every job after editing; deployments that set MAX_ACTIVE to bound scheduler load; assuming the cap applies to total jobs rather than enabled jobs.

Related errors

• Cannot create: maximum of ${activation.limit} active schedul
• Tools must be an array
• Invalid path name
• Run not found
• Failed to create workspace

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