for teams already using OpenTelemetry
Keep every exporter. Add release detection.
Your collector already has the hard part: connected application traces, runtime metrics, service identity and a place to fan them out. Keep every destination it has. Add Sixty as one OTLP/HTTP exporter, and the same telemetry becomes a release-by-release problem detector.
What it measures
- Connected HTTP, RPC and database spans
- Service operations, dependency edges, latency distributions, self time, errors, database-call counts and row counts when semantic attributes provide them. Trace relationships preserve which call belongs to which request.
- Useful semantic histograms
- HTTP and RPC duration histograms become a lower-fidelity operation baseline when traces are unavailable, instead of pretending an arbitrary custom metric describes application work.
- Runtime and pool pressure
- CPU and memory utilization, event-loop lag, garbage-collection pauses and database connection-pool pressure become bounded context attached to release findings.
- Service, environment and release identity
- service.name selects the service, deployment.environment.name separates production from staging, and deployment.revision or service.version anchors every comparison to what shipped.
What it finds
Every one of these is compared against the release before it, so the finding names the change rather than the day.
An endpoint that became slower after a release
Latency distributions are compared operation by operation and release by release, so a shared traffic spike is not presented as a code regression.
A database path that started doing more work
Connected database spans reveal call-count changes, added round trips, latency shifts and row-count changes when the instrumentation emits the semantic evidence.
Runtime saturation behind several slow operations
CPU, memory, event-loop, garbage collection and pool pressure corroborate a shared resource cause instead of blaming every endpoint independently.
A dependency that began failing or slowing down
Outbound spans remain dependencies rather than being folded into your own self time, so the evidence says which downstream service moved.
Telemetry that cannot support a comparison
A missing service.name is partially rejected, and a missing or unchanged release is surfaced as an ingestion state rather than producing an empty feed with no explanation.
What lands in your feed
Not a dashboard to read. One card per finding, with the numbers, the release that changed them, and the evidence your coding agent needs to write the fix.
Produced by apps/otel-demo-app in this repository. It sends six OTEL-only releases through the same public receiver, without a native Sixty agent.
GET /checkoutThe server span slowed down while runtime saturation and database-pool pressure rose across the same release window.
in the OTEL demo account, across six releases
GET /checkoutConnected database spans show that the request now performs more downstream work; the trace keeps those calls attached to the endpoint.
in the OTEL demo account, across six releases
How it installs
Add one exporter beside the destinations already in your collector. Do not replace receivers, processors, sampling, redaction or existing exporters, and do not create a logs pipeline for Sixty.
exporters:
otlphttp/sixty:
endpoint: https://ingest.sixty.sh
headers:
Authorization: "Bearer ${env:SIXTY_OTEL_KEY}"
compression: gzip
retry_on_failure:
enabled: true
service:
pipelines:
traces:
exporters: [your_existing_exporter, otlphttp/sixty]
metrics:
exporters: [your_existing_exporter, otlphttp/sixty]Validate and restart only the collector, then send traffic under two different release values. The MCP check_service tool confirms whether data and release identity are arriving.
What it does not do
- OTEL coverage is not native-agent parity. Native agents add automatic function spans, driver-specific query detail and source attribution that a generic trace cannot reconstruct. When sources overlap, native agent wins, then OTEL traces, then OTEL metrics.
- Sixty is not a trace warehouse. It retains bounded sketches and exemplars for comparison, not arbitrary trace search, dashboards or long-term raw telemetry exploration.
- OTLP protobuf logs are retained as bounded DriftStore investigation evidence, not as a general log-search product. Arbitrary custom metrics are rejected through OTLP partial success. Raw database statements are not retained because they may contain values.
- A gateway collector serving many applications must not stamp one global service.name. Set identity and release in each SDK or a service-specific resource processor.
If one of these is why you are here
Find out what your last change did.
Try it!Building something else? See Node services, Python services or Go services — those pages are different, and so is what we can see.