I’ve spent a good amount of time recently working in the App Builder, understanding its capabilities, and how some of it works. While there are a lot of examples in the form of blueprints that are provided by Datadog, figuring out how some more of the functionality really works has been tricky, since the documentation is still a work in progress. So, I did some of the hard parts, so you don’t have to!

Seems like there's a conference for everything, to the point where if you tried to attend all of them you would never get any work done. As an engineer, our time is valuable, and if we’re not gaining value in doing something then we shouldn’t be doing it.

Messy tagging slows down troubleshooting, clutters dashboards, and makes alerts unreliable. In Part 2, we’re tackling the biggest mistakes—over-tagging, inconsistent naming, and skipping Unified Service Tagging—plus how to fix them.

We received a lot of great questions in our webinar. Hopefully, this post helps answer those questions and provide even more detail than we could cover.

Woah now, hold on a second - get your mouse away from that “New Dashboard” button, we’ve got a few things to talk about first. Clearly you’re well on your way to using Datadog.

TL;DR: If your Datadog tags are messy, your observability is messy. Stop overcomplicating it—use layers, keep it practical, and only tag what matters.

Service Level Objectives (SLOs) sound simple—define what good service looks like, measure it, and call it a day. But getting them right is tricky.

Before we take the idea of observability and what it is off the rails, we should probably start with the boring definition of it just so we’re all on the same page.

Thanks for checking us out. We’re here because we’re done with BS in the tech and sales industries. We’re here to do things differently.