Decisions before tools
The platform must help teams decide better: which service is at risk, which customer is affected, and where to act first.
Ecosystem
The stack we work with, how we choose it, and shared experience with consultancies and integrators on observability projects.
Platforms
Stack we use most often. We also adapt to what you already run.
And other platforms: Checkmk, Datadog and other tools you already run in production.
Shared experience
Professional collaborations
Dot and Key has contributed to projects alongside consulting and technology integration firms. Links go to each company's corporate website.
Names and logos are property of their respective owners. Inclusion indicates professional collaboration, not mutual endorsement unless explicitly agreed.
Specialized guides
Focused pages for concrete observability problems.
How we choose technology
Integration with what already exists
We use the current stack when it makes sense. Replacing tools is not the goal; improving visibility is.
Cost designed from the start
Volume, cardinality, retention, and sampling are treated as architecture decisions, not after-the-fact tuning.
Maintainable operations
Dashboards, alerts, and runbooks must be sustainable by the internal team, with clear ownership and useful documentation.
Observability with AI (in development)
An agent to prioritize and analyze operational signal on your existing stack. Own product line in progress; exploratory conversation and scoped PoC.
Observability for AI workloads
Python services with LLMs in production: instrumentation with OpenTelemetry and OpenLLMetry, integrated into the observability backend you already use.
Let's talk about your stack and selection criteria
A first conversation to review current tools, fit, costs and real observability priorities.
Request a meeting