Batching two config changes destroys your ability to diagnose the regression

A booking system stopped sending host notification emails. Between the last known-good event and the first failure, TWO things had changed in one sitting: the destination calendar was repointed to a different provider, and the event type had been deleted and recreated to fix its display order. Both were reasonable individually; together they made the failure undiagnosable, because either could explain it and there was no single-variable comparison available. The recovery move is to find an event that occurred after only ONE of the changes, or to revert one change and reproduce. Also useful: look for a third event whose outcome is already known and which straddles the changes, since that partitions the timeline for free. Two related habits worth keeping. When a notification is missing, first establish WHICH mailbox should have received it: systems commonly send an attendee copy and a host copy to different addresses, and someone testing by booking their own link receives the attendee copy while real bookings only produce the host copy, so a test that appears to prove notifications work can prove nothing about the real path. And when notifications are unreliable, stop depending on them: poll the API for state and alert off that, which is both more reliable and independently verifiable. Deleting and recreating a resource to change its ordering also silently resets every setting on it, so re-verify configuration afterwards rather than assuming the recreate carried it over.