From a new account to an answered question

Three steps make the product work, and a handful of decisions make it work the way you want. This page is the whole path in order. Once you are signed in, the same steps appear on your dashboard as a checklist that watches the platform rather than asking you — a step is ticked when we can actually see it done, not when you say so.

3: steps before it is useful
OTLP: no proprietary agent to install
No card: the free plan needs no payment method

The checklist on your dashboard, two steps in. Each row is ticked from something the platform can see — the project it found, the issue your event was grouped into — rather than from your say-so, which is why the third stays open until a destination exists.

Before you start

You need an application that can make outbound HTTPS requests, and somewhere to put two environment variables. That is genuinely all — there is no agent to install, no sidecar to run and no daemon to keep alive.

If you already emit OpenTelemetry, you are changing an endpoint rather than adding instrumentation. If you do not, the browser SDK and the command line both come from npm and need Node 20.19 or newer.

Step 1 — Create a project

A project is one application. Most teams start with one and add another when a second service starts reporting, because issues, retention and inbound filters are all scoped to a project.

Creating one gives you a DSN. That string is the address your application sends to and the credential that identifies it, which is why it goes in the environment rather than in your repository. It is not a secret in the way an API key is — it only ever permits writing telemetry in, never reading anything out — but it still does not belong in a public commit.

Open Projects in the sidebar. It is under Management, near the bottom, not under Monitoring at the top.
Type a name in the New project card. Name it after the application, not the environment — staging and production belong in one project, told apart by the environment attribute your SDK already sends.
Click Create project.
On the project that appears, click Create DSN. Nothing sends until a DSN exists.
Copy the string it shows. It is shown in full once; step 2 is where it goes.

The New project card with the name Checkout API typed in and the Create project button outlined — One field and one button. The project appears immediately; the DSN comes from the Create DSN button on it.

The checklist on your dashboard confirms this one by reading your project list. If it still shows the step as outstanding, the project was not created — not merely unnoticed.

Step 2a — Copy the DSN

Creating the DSN shows it in full, once. Copy it before you leave the page: afterwards the project lists only a shortened prefix, enough to tell two keys apart and not enough to send with. Losing it is not a disaster — you can create another and revoke the first — but it is an avoidable detour.

How much of it you go on to use depends on which side you are on, and this is the detail worth reading twice before you paste anything.

The Your DSN card showing the full DSN string once, outlined, with an arrow labelled Copy this — The whole string is the DSN. In https://[email protected]/PROJECT, the KEY is the part between "https://" and the "@".

If you are using	You need
Our Go or JavaScript SDK	The whole DSN, as SNAGSPY_DSN in Go or the dsn option in JavaScript. The SDK splits it and sets the header itself, so you never handle the key.
Any other OpenTelemetry exporter, or a collector	Only the key. The rest of the DSN is not used: the endpoint is the ingest host, and the project is resolved from the key alone.

Step 2b — Paste it where your application reads its environment

That means wherever your variables already come from: the env block of a container, a Kubernetes secret, your platform’s config variables, or a local .env file if you are running on a laptop. Not your repository, and not your code — the DSN differs between your projects and the code should not.

The header must be named exactly `Authorization`, with the `Bearer` scheme. Ingest reads that one header and nothing else: a header under any other name is rejected exactly the way a missing one is, and the response does not tell the two apart. That is the single most common reason a first event never arrives.

The DSN above and the three environment variables below, with the key traced from one to the other and marked "this part only" — Not a screenshot of the product: this happens in your own deployment. It is the real configuration, with the key traced from the DSN to the one place it goes.

An existing OpenTelemetry exporter

OTEL_EXPORTER_OTLP_ENDPOINT=https://ingest.snagspy.com
OTEL_EXPORTER_OTLP_HEADERS=Authorization=Bearer%20<the key from your DSN, not the whole DSN>
OTEL_SERVICE_NAME=checkout-api

The %20 is a space, percent-encoded. OTEL_EXPORTER_OTLP_HEADERS is read as a list of URL-encoded pairs, so a literal space between "Bearer" and the key is not safe to write there. In a collector’s YAML, where no such encoding applies, write it with a real space: Authorization: Bearer ${SNAGSPY_DSN_KEY}.

Step 3 — Confirm the first event arrived

Do not take the absence of an error as success. Deploy the change, then make something fail on purpose — throw an exception on a route you can reach, or run a request that you know 500s.

The event should appear within seconds. If nothing arrives, the usual causes are, in order: the header is not named exactly `Authorization` (a config copied from a different backend often names it something else), the key was copied with a trailing space, egress to the ingest host is blocked by a firewall, or the exporter is buffering and the process exited before it flushed.

The Errors list with one issue, showing the exception type, the culprit frame, and one event — One arrived event, grouped into an issue by where it came from rather than by how many arrived. This is what "it worked" looks like.

This is the step the dashboard checklist proves rather than assumes: it reads your usage for the current period and only ticks when the event counter has actually moved above zero. Nothing else on the page can make that tick appear.

Step 4 — Choose where alerts reach you

Telemetry nobody is told about is an archive, not monitoring. A destination is either an email address or a webhook to a URL you own; the webhook address is checked before it is saved, so it cannot be pointed at a private network address.

Alert mail and digests arrive in the language set on the account, which is worth setting now if your on-call rota does not read English.

The alert destination form with a name and webhook URL filled in and the Add destination button outlined, above a destination already saved — Pick Webhook or Email, name it, paste the URL, add it. The saved row above shows what is kept afterwards: the host only, never the full webhook URL.

Three decisions worth making deliberately

None of these blocks anything, and all three are easier to decide now than to discover later. They live on the settings page.

What the AI may read

AI investigation of your telemetry is one switch, per organisation. Sending source code for review is a second, separate switch that starts off. Leaving either off is a valid answer, and the product keeps working.

How long data is kept

Seven, thirty or ninety days by plan. A scheduled job really deletes and the ceiling is applied again at read time, so this is a real boundary rather than a display setting.

What never gets stored

Inbound filters drop events at ingest, after scrubbing and before storage, so a filtered event is never written and never counted. Every rule shows what it removed.

What a finished setup looks like

A project exists, and its DSN is in your deployment environment rather than your repo.
Your event counter for this period is above zero, and you have seen a real error in the issue list.
At least one alert destination exists and has been tested with a real firing alert.
Everyone who might be woken up has an account.
The AI and retention settings say what you meant them to say, rather than whatever they defaulted to.

If something is not working

The two health endpoints on the status page answer without authentication, so you can tell a platform problem from a configuration problem before you write to anyone.

If it is a configuration problem, [email protected] is read by the people who built this. Include the project name and roughly when you sent the event that did not arrive.

Start at step one

Creating an account takes a form and no payment method. The checklist appears on your dashboard the moment you arrive, and disappears on its own once the three steps are done.

Create an account Read the setup guide