The cron job that had not run since March
Redirecting cron output to the null device is standard practice. It also turns a job that is failing into a job that appears not to exist.
Notes
Field notes on WordPress performance, security and the parts of a build that usually go wrong.
Your translated pages are serving yesterday’s prices
A translation proxy caches your page before it translates it. Anything that changes between visits is frozen in the translated copy, and the usual fixes do nothing.
A filter named after one form will fire on another
Checkout rejected a name that was plainly filled in. The validation was correct, and it was running somewhere its author never intended.
The order saved, the payment worked, and checkout showed an error
A bot-protection widget on a multilingual checkout can fail at the very last step, after the order exists. The customer sees a crash and orders twice.
A 524 is your server admitting it never answered
Gateway timeouts get blamed on the CDN. The CDN is reporting a fact about your origin, and usually about your PHP worker pool.
Your invoices are in the spam folder because of DNS
Order confirmations that never arrive are almost never a WordPress problem. Three DNS records decide it, and alignment is where it goes wrong.
Your script runs too late to change what the app already read
Filtering data in the footer does nothing when a JavaScript application consumed it halfway up the page. The window you need is narrower than you think.
Upgrading PHP on a server you cannot take down
The risk in a PHP major version upgrade is never the language. It is the plugin nobody has updated since 2019.
Verify the gateway’s response, not the string it hands you
Payment gateways sign their callbacks. Validate against the concatenation the gateway supplies and you have written a function that always returns true.
A backup you have never restored is a hypothesis
Backups fail silently and get discovered during the disaster. The only meaningful test is a restore you have actually performed.