You're not. The process that allowed this to occur was broken, and critical changes should only occur when you've confirmed someone is on site and available in the event you need a crash cart hooked up to a piece of gear (or perhaps automated rollbacks in the event of an unexpected state I suppose is the new hotness with software defined everything).

If you're making a change where you're unsure if someone can perform a physical recovery, you're flying without a chute. It works most of the time until it doesn't.

(infra/physical colocation/hosting/sysadmin in a previous life for ~20 years)

EDIT: @mprovost (HN is throttling me, so I have to reply to your comment here):

Absolutely. It's a combination of experience, context, and wisdom. I myself have made changes that I believed were trivial but, because I lacked context, data loss or an outage occurred. These are painful lessons to learn. A culture of psychological safety and commitment to continual process improvement are key, with shared responsibility between contributors and the org. You are going to fail, but you shouldn't get cold sweats when you do as long as you did your best to derisk.