hashicorp/nomad · error

total count was greater than configured job_max_count: %d >

Error message

total count was greater than configured job_max_count: %d > %d

What it means

The Job.Scale RPC enforces the agent's job_max_count server configuration: after applying the new group count, the job's total task-group count may not exceed the limit. Nomad throws this to cap cluster resource usage when a scale request would push the summed counts past the configured maximum.

Source

Thrown at nomad/job_endpoint.go:1049

					fmt.Sprintf("group count was less than scaling policy minimum: %d < %d",
						*args.Count, group.Scaling.Min))
			}
			if group.Scaling.Max < *args.Count {
				return structs.NewErrRPCCoded(400,
					fmt.Sprintf("group count was greater than scaling policy maximum: %d > %d",
						*args.Count, group.Scaling.Max))
			}
		}

		// Ensure that JobMaxCount is respected.
		newCount := int(*args.Count)
		totalCount := 0
		for _, tg := range job.TaskGroups {
			totalCount += tg.Count
		}
		totalCount = totalCount - group.Count + newCount
		if j.srv.config.JobMaxCount > 0 && totalCount > j.srv.config.JobMaxCount {
			return fmt.Errorf("total count was greater than configured job_max_count: %d > %d", totalCount, j.srv.config.JobMaxCount)
		}

		// Update group count
		group.Count = newCount
		job.SubmitTime = now

		// Block scaling event if there's an active deployment
		deployment, err := snap.LatestDeploymentByJobID(ws, namespace, args.JobID)
		if err != nil {
			j.logger.Error("unable to lookup latest deployment", "error", err)
			return err
		}

		if deployment != nil && deployment.Active() && deployment.JobCreateIndex == job.CreateIndex {
			return structs.NewErrRPCCoded(400, "job scaling blocked due to active deployment")
		}

		// If JobModifyIndex set, check it before trying to apply

View on GitHub (pinned to 482b49bf1a)

Solutions

  1. Raise job_max_count in the server configuration block and restart/reload Nomad servers
  2. Scale down another task group so the total stays under the limit
  3. Request a smaller newCount for this group
  4. If the limit is intentional, adjust the autoscaler policy bounds to respect it

Example fix

// before
# nomad server config
server { job_max_count = 50 }
// after
# nomad server config
server { job_max_count = 200 }
Defensive patterns

Strategy: validation

Validate before calling

job, _, _ := client.Jobs().Info(jobID, nil)
total := 0
for _, tg := range job.TaskGroups { total += *tg.Count }
newTotal := total - *group.Count + newCount
if newTotal > jobMaxCountLimit { return fmt.Errorf("new total %d exceeds job_max_count %d", newTotal, jobMaxCountLimit) }

Try / catch

_, _, err := client.Jobs().Scale(jobID, jobID, group, nil, uint64(newCount), "api", false, nil)
if err != nil && strings.Contains(err.Error(), "job_max_count") {
	return fmt.Errorf("scale rejected: raise job_max_count or scale down other groups")
}

Prevention

When it happens

Trigger: POST /v1/job/<id>/scale requesting a Target 'Count' such that (sum of all group counts) - (current group count) + newCount > job_max_count — e.g. scaling a group to 100 when job_max_count is 50 and other groups already use 10.

Common situations: Autoscalers (Nomad Autoscaler) scaling past a limit set by cluster operators; default job_max_count lowered for safety in shared clusters; legitimate growth that outlived the original capacity plan.

Related errors


AI-assisted analysis of hashicorp/nomad@482b49bf1a (2026-09-04). Data as JSON: /api/errors/6315d399501e2e93. Report an issue: GitHub.