{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/give-slow-kubernetes-startup-its-own-probe-budget/", "item": { "id": "https://update.dsesecurity.com/updates/give-slow-kubernetes-startup-its-own-probe-budget/", "slug": "give-slow-kubernetes-startup-its-own-probe-budget", "url": "https://update.dsesecurity.com/updates/give-slow-kubernetes-startup-its-own-probe-budget/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/give-slow-kubernetes-startup-its-own-probe-budget.md", "json": "https://update.dsesecurity.com/api/v1/posts/give-slow-kubernetes-startup-its-own-probe-budget/" }, "title": "Give slow Kubernetes startup its own probe budget", "summary": "Startup, liveness, and readiness checks answer different operational questions.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-20T18:14:43+00:00", "modified_at": "2026-10-20T18:34:31+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 261, "potentially_affected": "Review the separate startup, liveness and readiness decisions before changing a container's probe settings.", "dse_recommendation": "DSE recommends measuring normal and exceptional initialization before selecting a startup threshold.", "primary_source": { "name": "Kubernetes documentation — Configure Liveness, Readiness and Startup Probes", "url": "https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/", "published_on": null, "authority": "kubernetes.io" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

Startup, liveness, and readiness checks answer different operational questions.

\n

Source facts

\n

Kubernetes startup probes allow an application time to initialize before liveness takes over. A startup probe can also be used to delay readiness checks. If the documented example’s startup probe never succeeds, the container is killed and is subject to the Pod’s restartPolicy. A Pod whose containers report not ready does not receive traffic through Kubernetes Services.

\n

Source: Kubernetes documentation — Configure Liveness, Readiness and Startup Probes.

\n

Applicability

\n

Review the separate startup, liveness and readiness decisions before changing a container’s probe settings.

\n

DSE recommendation

\n

DSE recommends measuring normal and exceptional initialization before selecting a startup threshold. Write down what each endpoint proves: startup complete, process making progress, or ready to accept useful work. Avoid putting a remote dependency into liveness merely because it is convenient to check; decide separately how an unavailable dependency should affect traffic. Include a recovery path for failed initialization, and ensure the startup allowance fits the service’s operational expectations. Keep probe changes with the application configuration so a new image does not inherit unexplained timings.

\n

Verification

\n

In staging, test a normal start, an intentionally slow start, and a failed initialization. Observe probe events, restart count, and Service readiness. Confirm that an unready but running application is distinguished from one the kubelet must restart. Have the service owner identify a representative business request to attempt after readiness succeeds. Retain that result beside the probe events so endpoint success and useful service recovery remain separately observable.

\n

Official reference

\n

Kubernetes documentation — Configure Liveness, Readiness and Startup Probes. Reviewed October 20, 2026.

", "content_text": "Startup, liveness, and readiness checks answer different operational questions.\nSource facts\nKubernetes startup probes allow an application time to initialize before liveness takes over. A startup probe can also be used to delay readiness checks. If the documented example’s startup probe never succeeds, the container is killed and is subject to the Pod’s restartPolicy. A Pod whose containers report not ready does not receive traffic through Kubernetes Services.\nSource: Kubernetes documentation — Configure Liveness, Readiness and Startup Probes.\nApplicability\nReview the separate startup, liveness and readiness decisions before changing a container’s probe settings.\nDSE recommendation\nDSE recommends measuring normal and exceptional initialization before selecting a startup threshold. Write down what each endpoint proves: startup complete, process making progress, or ready to accept useful work. Avoid putting a remote dependency into liveness merely because it is convenient to check; decide separately how an unavailable dependency should affect traffic. Include a recovery path for failed initialization, and ensure the startup allowance fits the service’s operational expectations. Keep probe changes with the application configuration so a new image does not inherit unexplained timings.\nVerification\nIn staging, test a normal start, an intentionally slow start, and a failed initialization. Observe probe events, restart count, and Service readiness. Confirm that an unready but running application is distinguished from one the kubelet must restart. Have the service owner identify a representative business request to attempt after readiness succeeds. Retain that result beside the probe events so endpoint success and useful service recovery remain separately observable.\nOfficial reference\nKubernetes documentation — Configure Liveness, Readiness and Startup Probes. Reviewed October 20, 2026.", "content_markdown": "Startup, liveness, and readiness checks answer different operational questions.\n\n## Source facts\n\nKubernetes startup probes allow an application time to initialize before liveness takes over. A startup probe can also be used to delay readiness checks. If the documented example’s startup probe never succeeds, the container is killed and is subject to the Pod’s restartPolicy. A Pod whose containers report not ready does not receive traffic through Kubernetes Services.\n\nSource: [Kubernetes documentation — Configure Liveness, Readiness and Startup Probes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/).\n\n## Applicability\n\nReview the separate startup, liveness and readiness decisions before changing a container’s probe settings.\n\n## DSE recommendation\n\nDSE recommends measuring normal and exceptional initialization before selecting a startup threshold. Write down what each endpoint proves: startup complete, process making progress, or ready to accept useful work. Avoid putting a remote dependency into liveness merely because it is convenient to check; decide separately how an unavailable dependency should affect traffic. Include a recovery path for failed initialization, and ensure the startup allowance fits the service’s operational expectations. Keep probe changes with the application configuration so a new image does not inherit unexplained timings.\n\n## Verification\n\nIn staging, test a normal start, an intentionally slow start, and a failed initialization. Observe probe events, restart count, and Service readiness. Confirm that an unready but running application is distinguished from one the kubelet must restart. Have the service owner identify a representative business request to attempt after readiness succeeds. Retain that result beside the probe events so endpoint success and useful service recovery remain separately observable.\n\n## Official reference\n\n[Kubernetes documentation — Configure Liveness, Readiness and Startup Probes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/). Reviewed October 20, 2026." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/give-slow-kubernetes-startup-its-own-probe-budget/", "url": "https://update.dsesecurity.com/updates/give-slow-kubernetes-startup-its-own-probe-budget/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-20" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/give-slow-kubernetes-startup-its-own-probe-budget/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "IT", "item": "https://update.dsesecurity.com/topic/it/" }, { "@type": "ListItem", "position": 3, "name": "Give slow Kubernetes startup its own probe budget", "item": "https://update.dsesecurity.com/updates/give-slow-kubernetes-startup-its-own-probe-budget/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/give-slow-kubernetes-startup-its-own-probe-budget/#article", "identifier": "https://update.dsesecurity.com/updates/give-slow-kubernetes-startup-its-own-probe-budget/", "url": "https://update.dsesecurity.com/updates/give-slow-kubernetes-startup-its-own-probe-budget/", "headline": "Give slow Kubernetes startup its own probe budget", "description": "Startup, liveness, and readiness checks answer different operational questions.", "abstract": "Startup, liveness, and readiness checks answer different operational questions.", "articleBody": "Startup, liveness, and readiness checks answer different operational questions.\nSource facts\nKubernetes startup probes allow an application time to initialize before liveness takes over. A startup probe can also be used to delay readiness checks. If the documented example’s startup probe never succeeds, the container is killed and is subject to the Pod’s restartPolicy. A Pod whose containers report not ready does not receive traffic through Kubernetes Services.\nSource: Kubernetes documentation — Configure Liveness, Readiness and Startup Probes.\nApplicability\nReview the separate startup, liveness and readiness decisions before changing a container’s probe settings.\nDSE recommendation\nDSE recommends measuring normal and exceptional initialization before selecting a startup threshold. Write down what each endpoint proves: startup complete, process making progress, or ready to accept useful work. Avoid putting a remote dependency into liveness merely because it is convenient to check; decide separately how an unavailable dependency should affect traffic. Include a recovery path for failed initialization, and ensure the startup allowance fits the service’s operational expectations. Keep probe changes with the application configuration so a new image does not inherit unexplained timings.\nVerification\nIn staging, test a normal start, an intentionally slow start, and a failed initialization. Observe probe events, restart count, and Service readiness. Confirm that an unready but running application is distinguished from one the kubelet must restart. Have the service owner identify a representative business request to attempt after readiness succeeds. Retain that result beside the probe events so endpoint success and useful service recovery remain separately observable.\nOfficial reference\nKubernetes documentation — Configure Liveness, Readiness and Startup Probes. Reviewed October 20, 2026.", "datePublished": "2026-10-20T18:14:43+00:00", "dateModified": "2026-10-20T18:34:31+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/give-slow-kubernetes-startup-its-own-probe-budget/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/give-slow-kubernetes-startup-its-own-probe-budget/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Give slow Kubernetes startup its own probe budget" }, "articleSection": [ "IT", "Networks & Infrastructure" ], "keywords": [ "IT", "Networks & Infrastructure", "Guide", "Information priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 261, "timeRequired": "PT2M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Kubernetes documentation — Configure Liveness, Readiness and Startup Probes", "url": "https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/" } } ] } }