Everyone talks about the need for observability, it even comes up in board meetings. But let’s talk about the reasons you shouldn’t add observability to production.

Observability is the enemy: ten reasons​

1. Our users will tell us when the site is down​

If you’ve got a successful app, it’s likely that your users are testing every single route in your service every minute of the day. And if they really like using your service, then surely some of them will bother to let you know that your site is down before they sign up for a competitor. Chances are most of your reports will come via Twitter or Reddit, so be sure to keep an eye on those sites, really it’s better that way since you want everyone to know when your site is down.

As long as reports of your outage are spread far and wide, people will know not to bother you while you work on a fix. If users end up leaving your app for good? Perfect, you’ll reduce the overall load on the system!

2. Who needs an SLA?​

“Look, we’re sorry okay? That’s a lot, for us to apologize. It’s a big deal. I’m the BOSS here and I’m apologizing. That should be enough for you. What’s our plan for the next downtime? Well there won’t be a next time! Don’t worry, I’ll bully everyone from directors on down that this is not acceptable. I’ll get everyone terrified of the slightest outage. Isn’t that better than any so-called ‘contractual SLA’ with ‘guaranteed refunds on quarterly costs?’ There’s no need for that when I promised to yell at people, is there?“

3. It’s easier to reduce your developer velocity to zero​

Last outage, the CEO had to apologize. When’s that feature you want coming out? Never! All developer velocity is going to grind to a halt. That’s how committed we are to never having our boss have to apologize to a customer ever again. Hell if the boss has to so much as speak to an existing customer in the next year, it’ll be a failure on our part.

4. AWS needs to make their money​

Downscaling? resource overuse? You call it a wasted Operations budget, I call it stimulating the economy. Observability might be a great way to identify possible efficiencies, and even whole clusters that nobody is using, but really who needs the bother.

When the company has to massively reduce size due to budget overruns, then we can downscale whole departments at a time. And without observability, that should happen in no time!

How else will Jeff Bezos afford another 10-and-a-half minutes in the upper atmosphere?

5. We have logs at home​

Every system emits logs of some kind, and when you think about it the answers are always in there. Just because these logs are scattered across dozens of microservices, often with no clear connection between the request. But I’m sure with a few hours of digging and writing regex to connect disparate requests ID’s, you’ll find logs that give some clue about the cause.

Imagine doing this kind of digging while a critical service is down. All those angry messages from sales, support, and even direct from customers will certainly be motivating!

6. Post Mortem? Most Shmortem!​

Did a restart solve the problem during the last outage? Good enough for me! Is memory usage spiraling out of control? Nothing a restart can’t solve. Rather than finding a root cause, spend that time writing a cron job to restart services every few hours. And when it’s time to place blame a