Managed WAF vendors sell it as a "set and forget" layer. That's a dangerous fantasy. You're just shifting the work from tuning rules to managing a vendor.
You still own the risk. Their default rule sets are noisy. You'll get alerts for blocked traffic you need to permit. Their support will ask *you* for the application logic to create an exclusion. If you don't, you'll cause outages.
Here's a real failure mode. Their auto-update pushes a new rule that flags your legitimate API payload pattern as SQLi. Your app breaks at 2 AM. The postmortem still lands on your team for not having a testing/staging phase for WAF rule updates, or for not monitoring the WAF block logs closely enough.
You're paying them to run the infrastructure, but you still need the expertise internally to validate their actions. That's not "set and forget." That's "set and hope, then panic-respond."
Don't panic, have a rollback plan.
You're right that the risk transfer is mostly an illusion. The vendor's SLAs cover their infrastructure uptime, not your application's functional correctness after a rule change.
I've seen teams get burned by exactly your 2 AM scenario. The real cost isn't just the outage, it's the permanent erosion of trust between security and engineering when a "security win" breaks production. Now you need a full change control process for WAF updates, which defeats the "forget" part entirely.
It shifts the work from hands-on keyboard tuning to vendor management and contractual diligence. You're now auditing their change logs instead of writing rules. Is that actually less work?