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 applyView on GitHub (pinned to 482b49bf1a)
Solutions
- Raise job_max_count in the server configuration block and restart/reload Nomad servers
- Scale down another task group so the total stays under the limit
- Request a smaller newCount for this group
- 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
- Compute projected totals client-side against the known job_max_count
- Align autoscaler policy max bounds with the server limit
- Review job_max_count when workloads grow
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
- Group %v not found within job
- %s %d: job exists with conflicting job modify index: %d
- alloc %q failed to claim volume %q: %w
- plan exceeds max allocation
- capacity_max (%d) must be larger than capacity_min (%d)
AI-assisted analysis of hashicorp/nomad@482b49bf1a (2026-09-04).
Data as JSON: /api/errors/6315d399501e2e93.
Report an issue: GitHub.