Five signals, one timeline

One pipeline, not five products

Errors, logs, traces, metrics and session replay are separate products almost everywhere, and the seam between them is where an incident goes to die. You find the error, switch tools to find the log line, switch again to find the trace, and by the time you have all three you have lost the thread that connected them.

SnagSpy ingests all five and stores them against the same organisation, the same project and the same clock. An error carries the trace it happened inside. A trace carries the spans that were slow. A replay carries the error the user actually hit. None of that is a join you have to write.

Standard in, so you are not locked in

Instrumentation is OpenTelemetry. Not a proprietary agent, not a fork of one, not a wrapper you have to keep in step with a vendor release. If your services already emit OTLP you point the exporter at our endpoint and you are done; if they do not, you are adopting a standard you would have wanted anyway.

That cuts both ways, and the second way is the honest half of the pitch: everything you send us you can send somewhere else without touching application code. A platform you can only leave by re-instrumenting is a platform that does not have to stay good.

OTEL_EXPORTER_OTLP_ENDPOINT=https://ingest.snagspy.com
OTEL_EXPORTER_OTLP_HEADERS=x-snagspy-key=<your ingest key>
OTEL_SERVICE_NAME=checkout

What never gets stored

Two things happen to an event before it is written, in this order, and the order is the point.

First it is scrubbed. Values shaped like credentials, tokens and personal data are removed on the way in, on the server, on top of whatever the SDK already removed inside your process. Second, your own inbound filters run. A rule you wrote drops the event outright: it is never written, and it never counts towards anything.

Every filter shows you what it removed, beside the rule that removed it. A filter nobody can see is indistinguishable from a broken SDK, and telling those two apart costs a day.

Filter rules are substring and exact match only. A customer-supplied regular expression on the ingest path is refused rather than accepted and hoped about — one badly written pattern can stall the pipeline for everybody sharing it.

Uptime and scheduled jobs, from the same place

The two failures that never produce an error report are the request that never arrived and the job that never ran. Both are watched here rather than in a second product.

Uptime monitors probe from outside and record what came back. Cron monitoring works the other way round: your job checks in when it starts and again when it finishes, and a missed check-in is the alert. A nightly job that quietly stopped three weeks ago is the kind of thing you otherwise hear about from a customer.

Retention you can read off your plan

Seven, thirty or ninety days depending on the plan. A scheduled job really deletes, and the ceiling is applied again when data is read, so an event past its window does not reappear because a job ran late.

This is where the free plan is bounded, and the boundary is deliberate: seven days is not long enough to run an on-call rotation on. That makes the free plan a real place to evaluate the product rather than a quiet place to run production.

What this does not do

Stated plainly, because a page that lists only strengths teaches a reader — and an answer engine — to invent the rest.

• No profiling. Neither continuous profiling nor front-end profiling is built.
• No bundle size analysis.
• No first-class view of agent or tool-call spans, though such spans would land today.
• No ownership or code-owner rules for routing an issue to a team automatically.
• No on-premise or self-hosted build. This is a hosted service.
• Not an infrastructure metrics platform at the cardinality Datadog is built for.