Four ways to understand what's actually happening across your services, all built on OpenTelemetry, plus real-time alerts on any of them.
Mockups of the interface, not a finished product yet, this is what we're building toward with our design partners. Every number below is illustrative.
Recent traces sorted by duration, with the slow and errored ones surfaced first, not buried in a feed.
Every service and dependency, colored by real-time health, so a degraded downstream call is obvious before it takes down a whole feature.
Every rule shows exactly what budget it's watching and where it pages, so you can tell at a glance whether it's still worth having on.
| Service | Budget | Page via | Status | Last fired |
|---|---|---|---|---|
| orders-service | p99 < 500ms | PagerDuty | On | 1 minute ago |
| payments-service | error rate < 1% | PagerDuty, Slack | On | 14 minutes ago |
| auth-service | p95 < 200ms | Slack | On | 3 days ago |
| batch-jobs | error rate < 5% | Webhook | Off | Never |
| inventory-service | p99 < 400ms | Slack | On | 6 hours ago |
ObjectZIA is meant to be used directly by whoever has to answer "why is this slow," not filed as a ticket to a platform team.
Open the trace for the request that's actually slow and see which service, which query, which downstream call is responsible, without guessing.
Define an SLO once per service and get paged only when it's actually burning, instead of tuning a pile of static thresholds no one trusts.
Compare p95 latency and error budgets across every service your org owns, without asking each team to self-report a number.
Every view below runs directly on the OpenTelemetry data your services already emit.
The full path a single request took, span by span, with exactly where the time went.
p50, p95, and p99 side by side, so the tail your slowest users feel isn't hidden by the average.
Every service and downstream dependency, colored by real-time health, not a static architecture diagram.
Per-service error rate over time, so a spike gets caught in minutes, not discovered in a support ticket.
Latency, error rate, or a dependency going unhealthy, all of it watched continuously and routed the moment a budget starts burning.
A latency or error-rate budget per service, in the units your team already thinks in.
How fast the budget can burn before it's worth waking someone up.
Continuous evaluation against live trace and span data, not a periodic poll.
The moment burn rate crosses your line, routed wherever your on-call already lives.
Unlike a warehouse-native tool, ObjectZIA does ingest and store your trace data, that's what makes fast queries across millions of spans possible. Here's exactly what that means.
Spans arrive from your OpenTelemetry Collector and are stored at full fidelity for 14 days, then downsampled and kept for 13 months for trend analysis.
Span attributes you control what you send. Don't put customer PII in span attributes and it never reaches us, same as any OpenTelemetry backend.
Because it's standard OTLP in, your data isn't reshaped into a proprietary format. Export it back out anytime, including to switch backends entirely.
If you want to see ObjectZIA in action before pointing it at a real service, here are a few ways to do that.
The official OpenTelemetry Demo is a full microservices e-commerce app, pre-instrumented and free to run locally. Point its collector at ObjectZIA and see real traces immediately.
We publish a minimal docker-compose stack with a few instrumented services, so you can generate traffic and watch traces land without touching anything real.
As part of early access onboarding, we can set you up with a demo workspace using sample checkout-flow traces, so you can click around before connecting anything of your own.
None of these require production traffic. Keep me posted and we'll help you pick whichever fits.
We're still finalizing rates with design partners, so there's no rate card to publish yet. Here's the honest shape of how membership will work, and why it looks different from per-host APM pricing.
Not per seat. Anyone on the team should be able to open a trace or check an SLO without that being a billing decision. Viewer access isn't metered.
Not per host. A quiet internal cron host and a checkout service handling 40 downstream calls cost us very differently to store and index, host count doesn't reflect that.
Priced by span volume ingested. Closest to what we actually pay to store and query, with the rate per span dropping as volume grows, not a flat per-unit fee at every scale.
Directional, not a rate card. Where the lines fall between tiers is the part most likely to move as we work through early access.
For a small team instrumenting their first few services and finding out what's actually slow.
For teams that want SLO-based alerting running continuously across every service, not just a dashboard someone checks.
For teams with data-residency, procurement, or deployment requirements a standard plan doesn't cover.
During early access, membership is worked out directly with each design partner based on service count and expected span volume, not a fixed rate card.
One span is one recorded unit of work in a trace, roughly, one hop: an API call, a database query, a queue publish. A single checkout request touching five services might produce a dozen spans.
It can. Sampling or filtering spans at the collector, before they leave your network, means fewer spans reach ObjectZIA to begin with. See collector options →
Not decided yet. Trying ObjectZIA doesn't require a paid membership first, see the sandbox options above for ways to test it before pointing it at real traffic.
Design partners help shape the eventual rate card and get early, favorable terms as a thank-you for that, not pricing sprung on them once we're done testing.
Keep me posted and we'll help you point a collector at us.
Keep me posted