> ## Documentation Index > Fetch the complete documentation index at: https://docs.skyhook.io/llms.txt > Use this file to discover all available pages before exploring further. # Production Readiness > Evaluate services against an organization-wide checklist of reliability, security, and best-practice checks before they go live. Production Readiness lets your organization define a shared checklist of standards — probes, resource limits, security context, disruption budgets, and anything else you want to enforce — then scores every service against that checklist per environment. The feature is designed to answer one question: **is this service actually ready for production?** Readiness is evaluated at two levels: * **Organization-wide** (Settings → Production Readiness) — enable the feature, configure which checks apply, add custom checks, and see an aggregate score distribution across all services. * **Per-service** (service → Production Readiness tab) — see the service's score, what's failing, and how to fix it, with a breakdown by category. ## Enabling Production Readiness Readiness is off by default. An org owner enables it by selecting which environments and services to monitor. Navigate to **Settings > Production Readiness**. If readiness hasn't been enabled yet, you'll see an **Enable Production Readiness** card. Click **Get Started** to open the Environment Selection dialog. * Pick one or more environments to monitor. **Ephemeral (preview) environments are filtered out** — readiness only applies to static environments. * For each environment, either toggle **Select all services** or pick specific services. Click **Enable** to activate readiness checks for the selected service/environment pairs. Scores start populating as Skyhook evaluates each service. Once enabled, the settings page shows an **Add Environments** button in the top-right to extend coverage to additional environments or services. Existing selections are pre-populated so you only add what's new. ## Organization overview The settings page gives you a top-level view of readiness across your org: * **Org Score** — a weighted average of all evaluated services, shown as a large percentage with a visual score ring. * **Service compliance distribution** — how many services fall into each bucket: * **Excellent** (80–100%) — green * **Good** (60–79%) — amber * **Needs Work** (\< 60%) — red * **Unconfigured** — services with no checks enabled or with evaluation errors * **Checklist table** — every check in your org, with filters for category, importance, and recommended-only, plus a search box. Toggle checks on/off here without touching individual services. ## Per-service view Each service has a **Production Readiness** tab that shows how it's doing in a selected environment. Service production readiness tab showing 50% score, Passing 6, Failing 1, Warnings 3, N/A 2 counts, and the Issues Requiring Attention section with critical and medium priority items ### Score card * **Score** — 0–100, computed from passing checks weighted by importance. Labeled as **Excellent**, **Good**, **Fair**, or **Needs Work**. * **Environment selector** — switch between monitored environments for this service. * **Status counts** — how many checks are **PASSING**, **FAILING**, in **WARNING** state, or **N/A** (not applicable to this workload). ### Issues Requiring Attention Surfaces failing and warning checks grouped by importance — **Critical**, **High**, **Medium**, **Low** — so you fix the most important things first. Each item shows: * The check title and description * A **Docs** link to the relevant documentation * A **Fix** action where Skyhook knows how to resolve the issue — this often deep-links into the deployment configuration with the right field highlighted ### All Checks A category-grouped accordion showing every check that applies to the service. Each category (e.g. Reliability, Performance & Testing, Security, Best Practices, Custom Checks) shows a pass rate and count. All Checks section showing category groups - Custom Checks, Reliability, Performance & Testing, Best Practices, Security - each with a pass rate percentage Expanding a category reveals each individual check with its status icon, importance tag, and action buttons. Expanded Reliability category showing Readiness Probe Configured as Critical failing, Liveness Probe Configured as Critical passing, Multiple Replicas as High passing, and Pod Disruption Budget as Medium passing ### Status reference | Status | Meaning | | ----------- | ---------------------------------------------------------------------------------------- | | **Passing** | Check succeeded | | **Failing** | Check failed — counts against the score | | **Warning** | Check succeeded with caveats | | **N/A** | Check doesn't apply to this workload (for example, a stateful-set check on a deployment) | ## Custom checks Beyond the built-in checklist, organizations can author **custom checks** that match their own standards. Custom checks appear alongside the built-in ones in the service view and count toward the score. On the **Settings > Production Readiness** page, click **Configure Checks** and then **Create Custom Check** (top-right of the checklist table). Fill in: * **Name** and **Description** — what the check represents * **Importance** — Critical, High, Medium, or Low (drives sort order and weight) * **Apply to** — **All services** or **Select services** (picks specific services) * **Recommended** — flag the check as a recommended best practice * **Initial status** — what to report before anyone resolves it (defaults to **N/A**) * **Failure reason** — text shown to users when the check fails * **Suggested fix** — free-form guidance shown alongside the failure Custom checks are editable and deletable from the checklist table. Deletions require confirmation. Custom checks with `Apply type = All` automatically apply to every newly created service. Checks with `Apply type = Select services` only apply to services you explicitly pick. ## How scoring works * Each enabled check has an **importance level** (Critical, High, Medium, or Low) that determines how much it counts toward the score. * The service score is the percentage of passing checks, weighted by importance. Warnings partially penalize the score; N/A checks don't count for or against. * The org score is the average of all service scores across all monitored environments. * A service with no enabled checks, or whose evaluation errored, is counted as **Unconfigured** — it doesn't pull the org score down. ## Troubleshooting The service isn't enrolled in readiness monitoring. Open **Settings > Production Readiness**, click **Add Environments**, and add this service + environment pair. N/A means the check does not apply to this workload. For example, a StatefulSet-only check won't run against a Deployment. Check the category and description to confirm the check is intended for this workload type. Most built-in checks deep-link into the deployment config with the relevant field highlighted. If the link lands on the wrong tab, use the **Docs** link on the check to navigate manually — please also file an issue so we can fix the deep-link target. Readiness is visibility-focused today — it tracks and reports, but does not block deployments. For hard enforcement, combine a Kyverno policy (see [Policies](/infrastructure/gitops/policies)) with the readiness checklist so non-compliant configuration is caught at admission time.