Documentation

Five pages, in the order you need them. The first one ends with an issue on screen; the rest are what you do afterwards.

Start with the stack you ship

Quick start for FlutterInstall the Sentry Flutter SDK, point its DSN at Monitor, throw once, and watch the issue arrive.Quick start for Next.jsThe same DSN in the client, server and edge configs, and an issue that says which of the three it came from.Readable stack tracesWhat symbolication needs from your build on each platform, what Monitor stores, and what it does not.Moving from SentryPoint the app here, keep your Sentry DSN as the upstream, and compare both backends on your own crashes for as long as you like.TroubleshootingArranged by symptom, because that is how you arrive: nothing is appearing, stacks are minified, usage says things were refused, alerts are not coming.

What this service does with your data

Five more pages, and unlike the five above they are worth reading before you point anything at this rather than after.

PrivacyWhat an event carries, what is dropped before it is stored, what never leaves this platform, and the part of it that is your decision rather than ours.Retention and deletionWhat the nightly sweeper deletes and on what schedule, what a soft deleted project keeps costing you, and what deleting an organization takes with it.Service limitationsThe infrastructure this runs on, the single points of failure in it, and the platforms a real project has proved. Read before you rely on it.Terms and billingWhat the service is, what it may be used for, why nothing can be bought yet, and what happens to your data when you stop.Support and incidentsHow you find out something is wrong, what happens to events while it is, and what a reply from one person actually looks like.

The two values, and where each one comes from

Everything on these pages needs one or both of them, and they are not the same kind of thing.

The DSN is your project's address. It looks like https://<public key>@monitor.unrealops.ai/ingest/<project>, and you get it from the project's Monitor settings screen, on the key card. It is not a secret and it is safe to commit: it ships inside every copy of your app by design, and the key inside it can only write events, never read them.

The upload token is the one value on this platform that genuinely is secret. It is on the same screen, under Symbolication, and it belongs in a CI secret or an encrypted environment variable rather than in a repository. It lets a build machine spend your project's symbol storage, which is why the DSN alone is not enough to upload. It is derived from the project key rather than stored, so rotating the key rotates the token.

One DSN per project

Not one per environment, however tempting that is.

An environment is a label on the event, set by the SDK at runtime, not a property of the address it sends to. One DSN in the build and environment set from configuration means you can move a build between staging and production without changing the binary, and it means an app cannot end up with two DSNs in it and half its crashes in the wrong project. Monitor uses the key's own environment only as a fallback, for events that arrive without one.

Neither SDK sets an environment for you. Both quick starts show where to set it, and it is worth doing on the first day: without it every build reports the same environment, which is none, and a tester's crash is indistinguishable from a customer's.

The half that needs no app

Uptime checks, heartbeats and status pages have no page here, because there is nothing to install and nothing to paste into your code.

An uptime check is a url and an expected status, typed on the project's Uptime screen. The certificate expiry comes off the same handshake the check already makes, and the domain expiry is asked of the registry once a day, so neither is a second thing to set up. Checks run every five minutes, which is the schedule this deployment keeps rather than a number chosen to sound attentive, and a check is called down after three consecutive failures: an outage is noticed ten to fifteen minutes after it starts. Every screen that shows a frequency says that in the place you meet it.

A heartbeat is one line at the end of the thing you already run. The Jobs screen gives you the url and the schedule to compare it against, and pinging /start before the work and the bare url after it is what lets Monitor tell a job that hung apart from a job that never began.

A status page is built from those checks, public at a slug you choose or private to your organization, and it is created and edited on the Status page screen. Nothing about any of the three depends on which platform you ship.

What these pages do not cover

Because it does not exist, rather than because it is somewhere else.

React Native and Expo

Planned, with no code written. There is no set of instructions to give you, so there is no page pretending otherwise.

Session replay and profiling

Neither is stored. Both are acknowledged at ingest so your SDK does not retry them, then counted where you can see them on the usage screen. Transactions and log lines are a different matter and are stored, so tracing and enableLogs both work and both spend the same pooled event allowance your crashes come from. If you need replay, keep a Sentry DSN in the upstream field and it carries on being recorded there.

Paging and on call rotas

Alerts reach an email address, a Slack channel if you paste an incoming webhook url into the project's settings, and any https endpoint you register, signed and retried inside a deadline. What does not exist is a rota, an escalation policy or anything that phones a person, so nothing here wakes somebody up on a schedule.

An API for reading your data

The dashboard reads through an internal control plane API that is not documented or versioned for outside callers yet. Exports are not built either.