Seentics Observe
Logs, errors, traces and metrics for every service.
Your analytics says conversion dropped at 14:20. Observe shows you the request that broke, the bug behind it and the service it came from — in the same product, on the same clock.
OpenTelemetry native · no agent · included with your Seentics plan
Requests
ok vs failedLatency
p50 · p95 · p99Services
worst first| Service | Throughput | Errors | p50 | p95 | p99 | Logs | |
|---|---|---|---|---|---|---|---|
| payments-worker | 214/min | 18% | 740ms | 9.82s | 10.4s | 2.6k | |
| checkout-service | 288/min | 16% | 612ms | 9.64s | 10.4s | 4.2k | |
| api-gateway | 1.8k/min | 4.1% | 58ms | 1.92s | 9.71s | 8.4k | |
| notification-worker | 184/min | 0.4% | 88ms | 210ms | 412ms | 662 | |
| auth-service | 1.4k/min | 0.3% | 11ms | 28ms | 61ms | 1.4k | |
| catalog-service | 962/min | 0.1% | 34ms | 92ms | 180ms | 3.3k |
Top error groups
upstream timeout after 10000ms calling api.stripe.com/v1/payment_intents
checkout-service returned 502 for POST /api/v1/checkout
worker pool exhausted — 32/32 slots blocked on provider I/O
Search every line your services printed.
One query box over every service, with volume by level above it. Click a bar to narrow to the minute it happened in.
service:checkout-service duration_ms>2000 timeout- Field filters, numeric comparisons and free text in one box
- Live tail that holds its place when you scroll back
- Any line with a trace id is one click from its request
- The field panel counts what is actually in the matches
Forty thousand error lines. Nine bugs.
Faults are fingerprinted as they arrive — exception type, normalised message, top application frame — so the page shows the bugs rather than the volume.
- Ids and uuids normalised out, so one bug stays one row
- Users affected, first seen, and whether it is accelerating
- Resolve, ignore or reopen; a resolved group that fires again returns
- Sample events with the stack and a link to the trace
Watch one request cross every service.
The 10-second checkout is three sequential retries against a payment provider. Obvious in a waterfall, invisible in a log list.
- Search by service, operation, duration or status
- Latency scatter — click the outlier, land on its trace
- Span detail with attributes, events and exceptions
- Jump from a span to the logs written while it ran
The numbers behind the alert.
Latency percentiles, throughput, error rate, memory, queue depth — whatever your services export, grouped by any label they carry.
- Browse what is reported instead of guessing metric names
- Group by service, route, status class, host or queue
- p50 / p95 / p99, rate, sum, min, max — per panel
- Gaps stay gaps, so a stopped exporter looks like one
Why here
Your analytics already told you when. This tells you why.
Symptom to cause in four moves, without leaving the product.
- 01
Analytics
Checkout conversion falls off a cliff at 14:20.
- 02
Observe · logs
Log volume for 14:20 has an error band that was not there at 14:00.
- 03
Observe · errors
One group, accelerating: ProviderTimeout, 1,842 events, 396 users.
- 04
Observe · traces
The trace behind it: three sequential retries, 10.3 of 10.4 seconds.
One product, one session
The chart that dropped and the traces that explain it are behind the same login, scoped to the same site. No second tab, no second vendor, no re-explaining which service is which.
One clock
Both halves resolve the same window from the same URL. Most teams spend the first twenty minutes of an incident lining up two tools that disagree about what "last hour" means.
One bill
Observability is an allowance on the plan you already have — ingest volume and retention, not another seat count.
Setup
If you speak OpenTelemetry, you are done.
No proprietary agent, no sidecar, no rewrite. One OTLP endpoint takes traces, logs and metrics; anything that can POST JSON can send logs directly.
- 1
Create an ingest key
One key per project, scoped to that project only. Rotate or revoke it without touching anything else.
- 2
Point your exporter at it
Standard OTLP over HTTP. If you already run OpenTelemetry, this is two environment variables.
- 3
Read it beside your analytics
Traffic dropped at 14:20; the traces from 14:20 are one click away, in the same product.
# Every OpenTelemetry SDK reads these — no code change required.
OTEL_EXPORTER_OTLP_ENDPOINT=https://api.seentics.com/api/v1/observability/ingest
OTEL_EXPORTER_OTLP_HEADERS=Authorization=Bearer $SEENTICS_INGEST_KEY
OTEL_SERVICE_NAME=checkout-service
OTEL_RESOURCE_ATTRIBUTES=deployment.environment=production,service.version=2.14.3Pricing
Free to start. Pay for what you actually ingest.
Observability alone, or bundled with Analytics and Uptime in one suite plan.
Over your ingest allowance, writes are throttled rather than billed — nothing is charged that you did not agree to first.
FAQ
Questions worth asking first.
No. Ingest is OTLP over HTTP, so any OpenTelemetry SDK or collector already in your stack points at it with two environment variables. If you are not using OpenTelemetry, plain JSON log ingest works with anything that can POST.
Point one exporter at it and see.
Two environment variables, and the next incident arrives with a trace attached.