<p>I have a question regarding the status probe.</p>
<p>When I read the documentation, I understand that it's made mainly for applications that take a long time to start (like legacy applications). So in order to not kill the application (the container running it), we set up a startup probe to for example 5 minutes so the application has all the time to be able to start.</p>
<p>My question is: Why can't we just set a liveness probe (instead of using both liveness and startup probes) with the <em>initialDelaySeconds</em> parameter and set its value to something like 300 seconds?</p>

<p>Note the example given in <a href="https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/" rel="noreferrer">kubernetes docs</a>:</p>
<pre><code>livenessProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 1
  periodSeconds: 10

startupProbe:
  httpGet:
    path: /healthz
    port: liveness-port
  failureThreshold: 30
  periodSeconds: 10
</code></pre>
<p>The key difference between two probes here is not the delay - it's the fault tolerance. For startup probe, it's expected that app starts slow... sometimes. But most of the time it might be fast enough actually!</p>
<p>So the startup probe tries 30 times, waiting 10 seconds between each attempt, and considers its job completed on the first success, passing the token to liveness probe <em>immediately</em> after that.</p>
<p>With your approach, even if app has already started, the very first liveness probe on that <em>won't be fired until 300 seconds have passed</em> - regardless of whether or not app actually took ~300 seconds to start.</p>
<p>Of course, for apps that always require considerable amount of startup time, this approach might make sense.</p>
