<p>I was <a href="https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/" rel="noreferrer">reading the Kubernetes documentation about jobs and retries</a>. I found this:</p>

<blockquote>
  <p>There are situations where you want to fail a Job after some amount of
  retries due to a logical error in configuration etc. To do so, set
  .spec.backoffLimit to specify the number of retries before considering
  a Job as failed. The back-off limit is set by default to 6. Failed
  Pods associated with the Job are recreated by the Job controller with
  an exponential back-off delay (10s, 20s, 40s …) capped at six minutes.
  The back-off count is reset if no new failed Pods appear before the
  Job’s next status check.</p>
</blockquote>

<p>I had two questions about the above quote:</p>

<ol>
<li>The back-off limit value is on minutes or number of retries? The documentation example using the value <strong>6 (six)</strong> is confuse, because he initially affirms that the value is the number of retries but after that said "capped at <strong>six</strong> minutes".</li>
<li>There is a way to define the back-off delay time? As I understand, this behavior (10s, 20s, 40s …) is default and can't be changed.</li>
</ol>

<p>No confusion about the <code>.spec.backoffLimit</code> is is the number of retries.</p>

<p>The Job controller recreates the failed Pods (associated with the Job) in an exponential delay  (10s, 20s, 40s, ... , 360s). And of course, this delay time is set by the Job controller.</p>

<ul>
<li>If the Pod fails, after 10s new Pod will be created</li>
<li>If fails again, after 20s new one will be created</li>
<li>If fails again, after 40s new one comes</li>
<li>If fails again, next one comes after 80s (1m 20s)</li>
<li>If fails again, next one comes after 160s (2m 40s)</li>
<li>If fails again, after 320s (5m 20s), new Pod comes</li>
<li>If fails again, after 360s (not 640s, cause it is greater than 360s or 6m) you will see the next one </li>
</ul>
