Skip to main content
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.
1

Open Settings → Production Readiness

Navigate to Settings > Production Readiness. If readiness hasn’t been enabled yet, you’ll see an Enable Production Readiness card.
2

Select environments and services

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.
3

Enable

Click Enable to activate readiness checks for the selected service/environment pairs. Scores start populating as Skyhook evaluates each service.
4

Add more later

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

​
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.
1

Open the custom check dialog

On the Settings > Production Readiness page, click Configure Checks and then Create Custom Check (top-right of the checklist table).
2

Define the check

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
3

Save

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) with the readiness checklist so non-compliant configuration is caught at admission time.