My own monitoring always alerts if certificate chains don't validate, HTTP->HTTPS redirection is dead, or if the certificate is due to expire in less than 10 days.
The various tools for interacting with Lets Encrypt might fail sometimes, but if you have monitoring you can fix them up as required - and without monitoring you'll in trouble regardless of who you use.
OCSP out of the box is a call back to the issuing CA to verify that your certificate is still valid. Let's Encrypt like a lot of popular CAs implements this by having a CDN answer all live OCSP queries with bulk produced generic "This is still fine" answers for all the still-good certificates. But that means for any clients which check OCSP (some browsers do) that CDN is now on your critical path.
You can instead have your web server obtain (and periodically refresh) OCSP answers and "staple" them to its certificate when it answers HTTPS connections so that CDN isn't on your critical path any more.
However, some popular servers (most notably Apache HTTPD) do such a bad job of implementing OCSP Stapling that you're more likely to destroy your availability than improve it by enabling stapling (this is one of the things IIS actually gets right for a change), so make sure you understand what you're getting into. You will also need monitoring of the stapled response, because now if it's bad that might be a problem with your systems that you need to fix - whereas if Let's Encrypt OCSP is broken for the world you can be sure somebody else's on-call engineers are wrestling with it.