"Production-ready" is one of those phrases everyone uses and nobody defines, which means it usually resolves to "the person who has to approve it feels alright about it." That works until the approver is on holiday, or the service is somebody else's, or the pressure to ship is high enough that feelings become flexible.
Writing it down is worth doing once. It does not need to be long. It needs to be specific enough that two people would reach the same verdict.
Can you tell when it is broken
Before anything else. The service emits structured logs, exposes the handful of metrics that describe its user-facing behavior, and has a health check that fails when the service is genuinely unable to work rather than one that returns two hundred as long as the process is alive.
A shallow health check is worse than none, because it will keep a broken instance in the load balancer while reporting that everything is fine.
Can you tell when it is degrading
There is at least one alert, tied to a user-visible symptom, that fires before customers notice. It has a runbook attached, and the runbook has been read by somebody other than its author.
If the first indication of a problem is a support ticket, the service is not ready regardless of how well it works.
Can you get out
The deployment can be reversed, and the reversal has been performed at least once, not just documented. This includes the database question: if the release included a schema change, is going back actually possible, and has anyone checked?
Backward-compatible migrations are the usual answer here, and they are more work up front and much less work at 3am.
Does it fail in a contained way
Timeouts are set explicitly on every outbound call rather than inherited from a library default that is often measured in minutes. Retries are bounded and have backoff, so that a struggling dependency does not receive a thundering herd from you as well. Failures in optional paths degrade rather than take the request down.
Can someone else run it
More than one person knows how it works. Configuration is external and documented. There is no manual step that lives only in one person's shell history. Secrets are managed rather than pasted.
This is the criterion teams skip most often and regret most predictably, because it is invisible right up until the person leaves or is unavailable.
Use it as a conversation, not a gate
The temptation is to turn a list like this into a mandatory checklist with sign-off. That produces theatre. What works better is using it as a shared vocabulary: a service can be knowingly launched without a rollback path, as long as somebody has said so out loud and accepted it. The failure mode is not shipping something imperfect, it is shipping it while believing it was fine.