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 agent config option job_max_count caps the total task count a single job may request. When the summed count of all task groups (group count × tasks, as tallied by Validate) exceeds this cap, submission is rejected.

Source

Thrown at nomad/job_endpoint_hooks.go:550

		}

		for _, t := range tg.Tasks {
			if len(t.Identities) > 1 && !okForIdentity {
				multierror.Append(validationErrors, fmt.Errorf("tasks can only have 1 identity block until all servers are upgraded to %s or later", minVersionMultiIdentities))
			}
			for _, s := range t.Services {
				serviceErrs := v.validateServiceIdentity(
					s, fmt.Sprintf("task %s", t.Name), okForIdentity)
				multierror.Append(validationErrors, serviceErrs)
			}

			vaultWarns, vaultErrs := v.validateVaultIdentity(t, okForIdentity)
			multierror.Append(validationErrors, vaultErrs)
			warnings = append(warnings, vaultWarns...)
		}
	}
	if v.srv.config.JobMaxCount > 0 && totalCount > v.srv.config.JobMaxCount {
		err := fmt.Errorf("total count was greater than configured job_max_count: %d > %d", totalCount, v.srv.config.JobMaxCount)
		multierror.Append(validationErrors, err)
	}

	return warnings, validationErrors.ErrorOrNil()
}

func (v *jobValidate) isEligibleForMultiIdentity() bool {
	if v.srv == nil || v.srv.serf == nil {
		return true // handle tests w/o real servers safely
	}
	return v.srv.peersCache.ServersMeetMinimumVersion(
		v.srv.Region(), minVersionMultiIdentities, true)
}

func (v *jobValidate) validateServiceIdentity(s *structs.Service, parent string, okForIdentity bool) error {
	if s.Identity != nil && !okForIdentity {
		return fmt.Errorf("Service %s in %s cannot have an identity until all servers are upgraded to %s or later",
			s.Name, parent, minVersionMultiIdentities)

View on GitHub (pinned to 482b49bf1a)

Solutions

  1. Lower the job's group/task counts to fit under job_max_count
  2. Ask the operator to raise or unset job_max_count in server config if the limit is too restrictive
  3. Split the workload across multiple jobs to stay under the per-job cap

Example fix

// before
group "web" { count = 100 }
group "api" { count = 50 }   # total 150 > job_max_count 100
// after
group "web" { count = 60 }
group "api" { count = 40 }   # total 100 <= 100
Defensive patterns

Strategy: validation

Validate before calling

total := 0
for _, tg := range job.TaskGroups { total += int(*tg.Count) * len(tg.Tasks) }
if jobMaxCount > 0 && total > jobMaxCount {
	return fmt.Errorf("total count %d exceeds job_max_count %d", total, jobMaxCount)
}

Type guard

func withinMaxCount(total, max int) bool { return max <= 0 || total <= max }

Prevention

When it happens

Trigger: Registering a job where totalCount (sum over task groups and tasks) exceeds the configured JobMaxCount (>0).

Common situations: Operators setting job_max_count low to protect the cluster; autoscaling-generated jobs with large group counts; runaway count values in templated jobs (e.g. count = ${var} defaulted huge).

Related errors


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