FAQ

Setup, pricing and retention, data privacy, and how Observe relates to OpenTelemetry.

What is NestJS Observe?

An auto-instrumented observability platform built specifically for NestJS. Install the SDK, add a project API key, and your application starts streaming requests, jobs, errors, logs, and traces to a dashboard - no collector to run, no schema to design, no dashboards to build by hand. See Overview for how accounts, teams, projects, and applications fit together.

Can I see it before I install anything?

Yes - the live demo is the whole dashboard running over a generated dataset from a busy service: real request volumes, traces with waterfalls, errors, jobs and alerts. No signup, no credit card, nothing to install. It runs entirely in your browser, so nothing you do there touches an account.

What makes it different?

Auto-instrumentation is built around Nest's own request lifecycle - controllers, interceptors, guards, queue consumers - rather than a generic Node.js agent bolted onto the framework. That's also why the Services view can show you time spent per NestJS class and method, in the vocabulary you wrote the code in, instead of only per HTTP route.

How does the SDK work?

ObserveModule.forRoot() wires up automatic instrumentation for HTTP, RPC, gRPC, and job/queue consumers the moment your app boots - requests, errors, and traces show up in the dashboard within moments of your app receiving traffic, with no manual span wiring. TracerService is there for the rest: adding your own spans, capturing errors you handled yourself, and reporting custom metrics. See SDK for the full setup.

Does the SDK slow my application down?

Very little. In our benchmark it added about 0.1 ms to the median request at 150 requests a second, and 9-29 µs of CPU per request on a fully busy process, on endpoints with one to nine traced calls - roughly 8 µs per request plus 1-2.5 µs per traced call. Telemetry is compressed and sent from a worker thread, so an idle process spends under 1% of a core on it. See SDK → Performance overhead for the full numbers and how they compare with other Node.js agents.

Can I use it with an existing app?

Yes. Run npx @nestjs/observe link in the app's directory: it installs the SDK, wires it into your root module and main.ts, and fetches an API key into .env - and NestJS Observe starts collecting traces, logs, and errors from your existing application without any other changes. To do it by hand instead, install the SDK, make the three edits in SDK → Quick start, and add your project's API key. It requires @nestjs/core v11.1.4 or later, and - if your application uses GraphQL - @nestjs/graphql v13.4.4 or later, since earlier versions of either package lack the hooks the SDK needs for proper instrumentation.

Instrumentation isn't limited to REST: http, rpc, and grpc are each covered and configured the same way in ObserveModule.forRoot(), and queue consumers and cron jobs are covered by the SDK's job instrumentation - they get their own Jobs view, with queue wait time and retry attempts alongside the usual duration and failure rate. A request that fans out from your API into another HTTP or RPC service still resolves to one distributed trace, once that downstream service is set up to pick up the propagated trace id - see SDK → Propagating trace ids between services. Queue jobs need nothing extra: one added from inside a traced request carries that request's trace id to the worker that runs it (SDK 0.3.0 or later on both sides), while repeatable jobs, @nestjs/schedule handlers and jobs added outside any request start their own trace.

What's an Observability Event?

Usage is metered in Observability Events (OEs) - one per request, background job run, error, log entry, or trace span your applications report. Each plan includes a monthly allowance of OEs, and what happens beyond it depends on the plan: Free keeps recording requests, jobs and errors past its 300k events, with most traces arriving without their spans, and refuses new telemetry at twice the allowance until the next billing period; Pro and Scale allow overage instead of a hard stop, billed per extra million events, so a busy month doesn't mean lost data; spike protection pauses overage when usage surges, server errors still collected, and an optional monthly overage budget caps what it can cost. Free also pauses most waterfalls for the rest of any UTC day that passes 30k events, so one noisy day can't spend the month - see Free plan limits. Set quota notifications on the Usage page (up to five thresholds, e.g. 50%/80%/100%) to get an email before you find out from the invoice. See Billing & usage for the full pricing table.

Can I reduce telemetry volume?

Yes - spend controls, configured per project on Billing → Spend controls: sample spans on a noisy project, cap ingestion with a rate limit, or drop known-noisy traffic like health checks, all with no redeploy. Sampling and drop filters never remove errors, since they're low-volume and exactly what you want when something breaks. A rate cap is a circuit breaker rather than a filter - once it engages, everything above it is refused, errors included - so set it well above your normal peak. Cost attribution tells you which routes and jobs are worth targeting before you set one up.

Why is my Spans page empty when Usage shows spans?

Because they count different things. Every request your application serves records a whole tree of auto-instrumented spans - the controller, each service and repository call - and each one is a separate Observability Event under Spans on the Usage page. Database queries and outbound HTTP calls show up in the same tree but aren't billed. That's normally the largest slice of a project's volume. The Spans analytics page lists only the custom spans you named yourself with TracerService.createSpan(), so an application that never calls it has a busy Spans figure in Usage and an empty Spans page. The auto-instrumented ones are read per trace, in the waterfall on any request's detail page. To reduce the volume, turn on span sampling - it's trace-coherent, so sampled traces keep complete waterfalls.

How long is my telemetry retained?

Retention is set by plan: 3 days on Free, 30 days on Pro, 90 days on Scale, and a negotiated period on Enterprise. Data older than your plan's window is deleted automatically. This is also the ceiling for other time-based features - an SLO's compliance window, for instance, can't exceed how long your plan keeps the underlying data.

One exception, in the other direction: trace spans are kept for 7 days rather than the full window when the execution was both fast and successful - under 1 second, no 5xx, no failed job. Slow and failing executions keep their spans for the full window, and every execution keeps its own record either way. See Traces → How long waterfalls are kept.

What if I cancel or downgrade?

If you cancel, your plan stays on until the end of the period you've paid for - alerts, history and your team keep working - and the account moves to Free after that. Until that day you can keep the plan from the billing page. Your applications keep sending telemetry throughout. On a plan with shorter retention, older data expires sooner than it otherwise would: nothing is deleted at once, it just shortens how long new and existing data is kept from then on.

Where is my data stored, and who can see it?

On AWS in us-east-1 (N. Virginia, United States), encrypted in transit and at rest, with the database on a private network. Your applications decide what they send, and the SDK redacts secrets before anything leaves your process. NestJS is an EU company subject to the GDPR, and the Data Processing Agreement applies to every customer. Security & data lists what the SDK sends, how long it is kept, and every subprocessor.

Is my data redacted or identifiable?

Only what you choose to send, in both cases. When log forwarding (forwardLogs) is on, redaction is on by default the same moment it is - built-in patterns catch bearer tokens, JWTs, AWS key ids, PEM private keys, key=value secrets, and Luhn-valid card numbers, and you can add your own patterns or attribute-key names on top. Log forwarding itself is a Pro-and-above feature; see SDK → Logs.

For users, getUserId reports whatever identifier your app already uses for a person - a user id, an account id, a tenant-scoped id - and the dashboard treats it as an opaque string; it's never resolved into a name, email, or anything else. Reporting a user identifier at all is optional, and it's recommended you use an internal id rather than anything personally identifying. See Users.

Alerts vs. SLOs vs. Issues?

Alerts watch a metric and notify you the moment it crosses a threshold or deviates from its own baseline. SLOs are a longer-horizon view on top of the same telemetry - "99.9% of requests under 300ms over 28 days" - with an error budget and burn rate instead of a single reading; a burn-rate alert is just a regular alert rule pointed at an SLO. Issues are where the resulting work gets tracked - create one by hand, or have a firing alert open one automatically, pre-filled with severity and a link back to the telemetry that triggered it. See Alerts, SLOs, and Issues.

Can I get notified if my app goes silent?

Yes, that's absence detection: a Telemetry silence rule fires once an application has gone quiet longer than a tolerance you set (2 minutes to 7 days), using the same runtime heartbeat the Profiler samples. A Job silence rule does the same for one named job, or for any job in the project if left unscoped. Neither fires on a scope that has never reported anything - "not yet integrated" isn't treated as "down." See Alerts → Absence detection.

Does it support SSO and access roles?

SSO is available on Scale and Enterprise - configure a connection under Teams → SSO & 2FA, verify the domains that should route through it, and enforcement only takes effect once you explicitly switch it on. On every plan, a team's owner can also require two-factor authentication of everyone in the team, from the same page. On Pro and above, the owner has an audit log of who changed the team's members, roles, sign-in rules and API keys, and from where. Independently of both, every project member has one of three access levels - Read, Write, or Admin - controlling whether they can view telemetry, make changes, or manage members, settings, and billing. See Applications → Single sign-on and Overview → Access control.

How does Observe relate to OpenTelemetry?

Observe works on its own, or beside the OpenTelemetry you already have - it isn't a replacement for it. OpenTelemetry is the vendor-neutral standard for instrumenting services in any language. Observe covers the Nest services in your system, whether that's all of your backend or part of it: it instruments the framework from the inside, so every controller, provider, guard and queue consumer becomes a span named the way you wrote it, and tracing, error monitoring, logs and alerting come hosted, with no collectors, storage or dashboards of your own to run. Services written in other languages share its traces through OpenTelemetry: where they already use it, your Nest services join the same traces, and can export their spans to your OpenTelemetry backend as well. Observe doesn't ingest OTLP, so the other services' spans stay in that backend. See SDK → Running beside OpenTelemetry.

We already run OpenTelemetry. Can we use Observe for just our Nest service?

Yes. Turn on openTelemetry in the SDK and the Nest service joins the traces your other services already share: it reads and sends the W3C traceparent header, and if it runs the OpenTelemetry SDK itself, each request is reported under the SDK's trace id. A request then has one trace id in both tools, and Observe shows the Nest service's spans, down to each provider method. Set otlp as well and the SDK exports those spans to your OpenTelemetry backend too, so the whole trace is in one waterfall there - on every plan, with Free exporting what Observe keeps under its daily pacing and monthly allowance. Observe doesn't take spans from an OpenTelemetry backend. See SDK → Running beside OpenTelemetry.