About
We built Simple Observability because every tool we used made the same mistake: solving complexity with more complexity. Here's how we think differently.
Opinionated by design
Most tools try to support every use case, so they end up supporting none of them particularly well. You get infinite flexibility, no sensible defaults, and a configuration surface that grows faster than your team can keep up with. Six months in, nobody fully understands how the alerts are wired together, and every change is a small act of faith.
We do the opposite. We make tradeoffs on purpose: fewer knobs, better defaults, and one coherent mental model. We remove decisions you shouldn't have to make. We'd rather give you a system that works well out of the box than one you can theoretically bend into any shape, eventually, after a few days of YAML and Stack Overflow.
One system, not a stack
Every component of the classic monitoring stack (metrics, logs, alerts, etc) shouldn't be separate products loosely bolted together here. They're first-class citizens in the same workflow.
You shouldn't need to context-switch between tools to understand what's happening in your infrastructure. Think of it as the operating system for your infrastructure. All elements stem from the same physical entity—a server—and should thus all be linked because nothing happens in isolation.
A lightweight agent that respects your machines
The collector is written in Go, it's small, resource-efficient, and it does what it says it does. You can read the source and know exactly what's happening.
We think an agent that lives inside your infrastructure should earn that position through transparency and predictability, not just because it was the easiest thing to install. We respect your machines enough not to treat them as a deployment target for our complexity.
Setup in minutes, not hours
There's no YAML to write before you see anything useful. You connect, data appears, you move on. Everything is visible and editable in the UI. Configuration isn't a prerequisite for getting started, it's something you reach for when you actually need it. Complexity reveals itself progressively, and sensible defaults carry you most of the way there.
It should feel like a product, not a toolkit someone left half-assembled in your garage.
Engineer-to-engineer support
We deliberately skipped the SaaS support hierarchy. There is no account managers, no tiered response SLAs, no ticket queue that routes your question through three people before it reaches someone who can actually answer it. When something breaks or doesn't make sense, you're talking directly to the people who built it. They know where the bodies are buried because they buried them, which means answers are faster and more accurate than anything a support tier can offer.
You shape the product
We don't do roadmap theater. If you tell us something is broken, backwards, or missing, it goes into the next build. Users here aren't customers of a finished product. They're participants in building it, and that's only possible because we're a small, focused team with no interest in becoming the everything platform.
We're just trying to be the right tool for engineers who want observability that works without becoming a second job.
— The Simple Observability Team