The 14-Point Readiness Engine
The hardest part of deployment is not building the code or starting the container; it is knowing when the new release is actually ready to receive traffic. A container that starts successfully is not necessarily healthy: it might be returning 500 errors, it might have a missing environment variable that only manifests under load, it might have a broken database connection that the health check does not catch. Swapping traffic to a container that is technically running but not functionally healthy is how you break production. We built the 14-point readiness engine to solve this: before swapping traffic, we run 14 checks that cover the most common failure modes, and we assign an A-to-F grade that tells you (and your AI assistant) exactly how ready the release is. Here is what each check does, why it matters, and how the grade is calculated.
The direct answer is that the readiness engine runs 14 checks against the new release, covering SSL, DNS, environment variables, health endpoints, container status, resource usage, database connectivity, build status, rollback availability, custom domain configuration, auto-repair status, log errors, and overall stability. Each check returns a status (pass, warn, fail) and a human-readable explanation. The overall grade is calculated from the individual check results: A (all checks pass), B (one or two warnings), C (several warnings or a single non-critical failure), D (a critical failure), F (multiple critical failures). Traffic is only swapped when the grade is A or B; lower grades trigger a rollback.
The 14 Checks
Here is what each check does and why it matters.
1. SSL Certificate
The SSL check verifies that the SSL certificate for the custom domain is valid, not expired, and not expiring soon (within 30 days). An expired or invalid SSL certificate causes browser warnings, which destroy user trust. This check catches certificate renewal failures before they affect users.
2. DNS Resolution
The DNS check verifies that the custom domain resolves to the Deployxa infrastructure. A misconfigured DNS record (wrong CNAME, missing A record) means users cannot reach your app. This check catches DNS configuration errors before they affect users.
3. Environment Variables
The environment variable check verifies that all required environment variables are set. The pre-flight scanner identifies required variables based on the app's framework and dependencies (e.g., DATABASE_URL for Prisma, NEXTAUTH_SECRET for NextAuth). This check catches missing variables before the container crashes on boot.
4. Health Endpoint
The health endpoint check polls the app's /health endpoint (or a configurable path) and verifies that it returns a 200 status code. A non-200 response indicates that the app is not functioning correctly, even if the container is running. This check catches application-level errors that the container status check misses.
5. Container Status
The container status check verifies that the container is running and stable (not restarting repeatedly). A container that is crash-looping (starting, crashing, restarting) is not healthy, even if individual health checks pass during the brief windows when the container is up. This check catches crash loops before they affect users.
6. Memory Usage
The memory usage check verifies that the container's memory usage is within healthy limits (typically under 80 percent of the allocated RAM). A container that is using too much memory is at risk of an out-of-memory kill, which causes a crash. This check catches memory leaks before they cause crashes.
7. CPU Usage
The CPU usage check verifies that the container's CPU usage is within healthy limits (typically under 80 percent sustained). A container that is using too much CPU is either overloaded (needs more resources) or has a bug (infinite loop, inefficient algorithm). This check catches performance issues before they degrade the user experience.
8. Database Connectivity
The database connectivity check verifies that the app can connect to its database. This is typically done by running a simple query (e.g., SELECT 1) through the app's database client. A failed database connection means the app cannot read or write data, which is a critical failure. This check catches database connectivity issues before they affect users.
9. Build Status
The build status check verifies that the last build succeeded. If the build failed (and the AutoRepairService could not fix it), the new release is not deployed, and traffic stays on the previous release. This check ensures that a failed build never receives traffic.
10. Rollback Availability
The rollback availability check verifies that there is a previous release to roll back to. If the new release fails, the platform needs to be able to roll back to the previous release. This check ensures that the rollback path is available before the traffic swap.
11. Custom Domain
The custom domain check verifies that the custom domain is configured correctly (DNS, SSL, routing). A misconfigured custom domain means users cannot reach your app at your desired URL. This check catches domain configuration errors before they affect users.
12. Auto-Repair Status
The auto-repair status check reports whether the AutoRepairService ran on the last build, and if so, what it fixed. This is informational, not a pass/fail check, but it helps you understand what the platform did to make the build succeed.
13. Log Errors
The log errors check scans the container's recent logs for error patterns (e.g., Error, Exception, FATAL). A high error rate in the logs indicates that the app is malfunctioning, even if the health check passes. This check catches application-level errors that the health check misses.
14. Overall Stability
The overall stability check verifies that the container has been running stably for a minimum period (typically 30 seconds) without restarts. A container that just started might pass all other checks but crash a minute later. This check ensures that the container is stable before receiving traffic.
How the Grade Is Calculated
The overall grade is calculated from the individual check results:
- A: All 14 checks pass.
- B: One or two checks return warnings (non-critical issues that should be fixed but do not block deployment).
- C: Several checks return warnings, or one check returns a non-critical failure.
- D: One or more checks return a critical failure (e.g., health endpoint returning 500, database connectivity failed).
- F: Multiple critical failures, or the container is crash-looping.
Traffic is only swapped when the grade is A or B. Lower grades trigger a rollback, and the developer is notified with the specific failing checks and recommended fixes.
Step-by-Step: What Happens During a Deployment
Here is what happens during a typical deployment, from the developer's perspective.
Step 1: Push and build
The developer pushes code, and the build runs. The AutoRepairService stands by to patch any missing dependencies.
Step 2: Container starts
The build succeeds, and a new container starts. Traefik adds the container to its routing table but does not route traffic to it yet.
Step 3: Readiness engine runs
The 14-point readiness engine runs against the new container. Each check takes a few seconds, and the total time is typically 30 to 60 seconds.
Step 4: Grade is calculated
The engine calculates the overall grade based on the individual check results.
Step 5: Traffic swap or rollback
If the grade is A or B, Traefik swaps traffic to the new container atomically. If the grade is C, D, or F, the platform rolls back to the previous release, and the developer is notified with the specific failing checks.
Step 6: Verification
After the traffic swap, the readiness engine runs again to verify that the new release is healthy under real traffic. If issues are detected, the platform can roll back automatically.
Step 7: Notification
The developer is notified of the deployment result, including the readiness grade, any warnings or failures, and the URL of the new release.
How This Integrates with the MCP Server
The readiness engine is exposed via the Deployxa MCP server as the deployxa_get_readiness and deployxa_doctor tools. This means your AI assistant (in Cursor or Claude Desktop) can call the readiness engine directly and reason about the results.
For example, you can say: "Deploy my app and tell me if it is healthy." Your AI assistant calls deployxa_deploy_workflow, waits for the build, calls deployxa_get_readiness, and reports back: "Deployment succeeded. Readiness grade: A. All 14 checks pass. Your app is live at https://my-app.deployxa.app."
If there are issues, the assistant can diagnose them: "Readiness grade: D. Failing checks: database connectivity, health endpoint. The database connectivity check failed because DATABASE_URL is not set. Would you like me to set it?"
This integration makes the readiness engine accessible to vibe coders who might not know to check the dashboard. The AI assistant proactively reports the readiness grade and any issues, so the developer always knows the state of their deployment.
Why This Matters for AI-Generated Apps
AI-generated apps are more likely to have subtle issues that pass the build but fail in production. Missing environment variables, hardcoded localhost URLs, broken database connections, and crash loops are all common in AI-generated code, and they do not always manifest during the build. The readiness engine catches these issues before traffic is swapped, which means the developer gets feedback quickly and can fix the issues before users are affected.
Without the readiness engine, the developer would have to manually check the deployment after each push, which is tedious and error-prone. With the readiness engine, the platform does the checking automatically, and the developer only needs to act when there is a problem.
Comparison with Other Platforms
Here is how Deployxa's readiness engine compares with other platforms:
Vercel
Vercel has a simpler health check (typically just checking that the deployment responds to HTTP requests). It does not have a multi-point readiness engine, and it does not assign a grade. Vercel's deployments are atomic (no downtime), but the health checking is less comprehensive.
Railway and Render
Railway and Render have basic health checks (container status, HTTP response), but they do not have a multi-point readiness engine or a grading system. Deployments can fail silently if the container starts but the app is not functioning correctly.
AWS (ECS, EKS)
AWS has target group health checks, which are configurable but typically limited to HTTP response checks. AWS does not have a multi-point readiness engine or a grading system. Configuring comprehensive health checks in AWS requires significant manual effort.
Extending the Readiness Engine
The 14-point readiness engine covers the most common failure modes, but it is designed to be extensible. Deployxa supports custom health checks, which let you add app-specific verification to the readiness engine. For example, if your app has a critical API endpoint (e.g., /api/checkout for an e-commerce app), you can add a custom check that verifies the endpoint returns a 200 status code. The custom check runs alongside the 14 built-in checks, and its result is included in the overall grade. The first step to adding a custom check is to define the check in your Deployxa dashboard: specify the name, the HTTP endpoint to check, the expected status code, and the timeout. The second step is to test the check by running deployxa doctor and verifying that the custom check appears in the report. The third step is to configure the check's weight in the overall grade. By default, all checks have equal weight, but you can assign higher weight to critical checks (e.g., the checkout endpoint check) and lower weight to non-critical checks (e.g., the SSL certificate expiry warning). The fourth step is to configure the check's failure behavior: should a failure block the traffic swap (critical), or should it just produce a warning (non-critical)? Critical failures trigger a rollback, while non-critical failures produce a warning but allow the traffic swap to proceed.
Integrating with CI/CD Pipelines
The readiness engine is not just for platform-level deployment verification; it can also be integrated into your CI/CD pipeline for pre-deployment testing. The pattern is to run deployxa doctor as a step in your CI/CD pipeline, after the build but before the traffic swap. If the readiness grade is below a threshold (e.g., below B), the pipeline stops and the traffic swap is skipped. This prevents broken releases from reaching production, even if the build itself succeeded. For teams using GitHub Actions, Deployxa provides a reusable action that runs the readiness check and fails the workflow if the grade is too low. For teams using other CI/CD tools (e.g., GitLab CI, CircleCI, Jenkins), the Deployxa CLI can be called directly from a script step. The key insight is that the readiness engine is a composable building block: it runs as a standalone check, it integrates with the Deployxa platform for traffic swap decisions, and it integrates with external CI/CD pipelines for pre-deployment verification. This composability makes the readiness engine a versatile tool for ensuring production safety at every stage of the deployment pipeline. For teams that are serious about production reliability, the recommendation is to use the readiness engine at every stage: pre-deployment (in CI/CD), at deployment (for traffic swap decisions), and post-deployment (for ongoing monitoring). This multi-layered approach catches issues at the earliest possible stage, which minimizes the impact on users and reduces the time spent debugging production incidents.
Conclusion: Score Before You Swap
The 14-point readiness engine is our solution to the hardest part of deployment: knowing when the new release is actually ready to receive traffic. By running 14 checks and assigning an A-to-F grade, the engine gives you (and your AI assistant) a clear, actionable signal about the state of your deployment. Traffic is only swapped when the grade is A or B, which means broken releases do not reach your users.
Ready to deploy with confidence? Drag your project to Deployxa Drop for an instant live preview, or install the CLI with npm i -g @deployxa/cli and deploy from your terminal. For more on Deployxa's engineering, see our free developer tools and read about the AutoRepairService and Traefik v3 routing.