Monitor takes Sentry format envelopes from the MIT licensed SDK you already use, groups them into issues, keeps the stack trace readable, and tracks crash free sessions per release. There is no SDK of ours to install and no proprietary wire format to migrate off later. Flutter and Next.js are the platforms available today; the rest of the list is below, with its real standing next to it.
It watches the other half too, the failures that happen while none of your code is running: a site that stopped answering, a certificate or a domain about to lapse, a nightly job that did not fire. Those need no SDK and no platform, only a url. What comes out of them can drive a status page, public or private, and reach you by email, Slack or a signed webhook.
You can create an account, and the next screen has your DSN on it. What does not exist is billing: the prices further down are published rather than charged, so there is no checkout and no trial, and every account is on the free plan whichever tier it picked. That plan stops at its limit rather than billing you for going past it, which is the same way the paid ones will work.
This table is the whole list. A Sentry SDK exists for plenty of other platforms and would happily send this ingest a compatible envelope, which is not the same thing as support: native iOS, native Android, Node and everything else are missing here on purpose and stay missing until a real project proves them.
Verified end to end by doing it rather than by reading code: real envelopes grouped at the live endpoint, symbols uploaded at build time and traces returned readable, release health per release, and an alert email actually delivered.
Verified end to end against a real production site, on both halves of the build: a deliberate browser crash and a deliberate server crash from a route handler each resolved back to a real file and line in that site's own repository, through maps the build uploaded. The server half is a per project setting and is off by default, because it spends your pooled symbol allowance on a half not every project needs read; measured on that site it stores about 2.3 MB a release against the browser half's 0.8 MB.
Planned, with no code written. It is explicitly not a blocker for anything above it.
Planned alongside React Native, with no code written.
Every item below is something the running system does today. Where an item needs an SDK in your app, it works on the platforms marked Available above; where it only needs a url, it does not care what you built the thing in. Where something is missing, or is built and not yet proved on one of the two platforms, it says so here or further down rather than being left out.
Events are fingerprinted and grouped into issues, with first seen, last seen, event count and how many distinct devices are affected. The grouping rule and its inputs are shown on every issue, so a surprising group can be explained rather than argued with.
In app frames get the rail and full contrast. Runs of framework frames fold away behind a single line. The exception chain is rendered as a chain, so a wrapped error does not hide the cause that actually matters.
Upload the debug symbols your release build produces and a production trace comes back with your file names, line numbers and function names. The address table is extracted once and the uploaded artifact is discarded, so what is kept is the answer rather than the file. Every frame is marked symbolicated, unsymbolicated or symbols missing, and a missing frame names the symbol file it wanted.
The trail leading up to a crash in the order it happened, timed as an offset from the crash rather than a wall clock, alongside device, operating system, app, runtime and release context.
Crash free sessions and crash free users per release, with the comparison against the release it replaced. Where a rate cannot be computed honestly, it says so instead of rendering a zero.
A new issue, a regression on a new release, a site that went down or a job that did not run sends one notification. One decision owns the recipients, the mute, the cooldowns and the burst brake, and the three channels are three ways of saying it rather than three ledgers, so a crash loop costs one message on each rather than four hundred. A webhook is signed over the timestamp and the body together, so a captured delivery cannot be posted at you again next week, and rotating a secret keeps the old one valid for a day so the receiver never has an outage.
A check every five minutes, which is the schedule this deployment can actually keep rather than a number chosen to sound attentive, and three consecutive failures before it is called down. So an outage is noticed ten to fifteen minutes after it starts, and the screen says that instead of implying a continuous watch. The certificate's expiry is read off the handshake the check already made, so it costs nothing extra. The domain's expiry is an RDAP query to the registry, asked once a day at most, and a registry that will not answer is shown as unanswered rather than guessed.
A bare curl on the end of a crontab line. Nothing to install, nothing to sign, because a shell script cannot be asked to construct a signed request. Ping at the start and again at the end and a job that started and never finished reads differently from one that never started. A grace period means late is a state on the screen rather than an email, and the last twenty runs are kept so you can see whether last night was unusual.
Components driven by the checks above, an incident opened automatically when one goes down, maintenance windows that suppress what they cover, and subscribers who confirm by email first. A public page carries no identifier of any kind from inside this platform, and when it cannot be rebuilt it serves the last answer that worked with its age on it, because a status page answering 500 turns we are having trouble into we have gone away.
Transactions with the span tree underneath them, and log lines searchable beside the release and the trace they belong to. Both are off in every Sentry SDK until you turn them on. A transaction costs one event and ten log lines cost one event, which is the ratio of what they cost to store rather than a number anybody picked, and the two together may take at most two fifths of a month, so a month of tracing can never leave you with no crash reports. Log lines are scrubbed before anything is written, so there is no unredacted copy here to leak later. Both were built against the JavaScript SDK's own wire shapes and are proved on Next.js; the same ingest accepts them from Flutter and nothing in the path is platform specific, but that has not been driven end to end.
A view is a screen and a query string, not a copy of the data, so it cannot go stale or disagree with the screen it opens. The health screen composes what the other screens already know rather than counting anything itself, and it says where alerts go, because a project whose alerts go nowhere looks exactly like a project with nothing wrong.
A per minute ceiling catches a crash loop within sixty seconds. A monthly ceiling catches the slow bleed. Over either one, ingest answers 429 with Retry-After and the SDK stops sending, and every drop is counted by reason.
Monitor shares tenancy, keys and audit with the products queued behind it, so adding a second product does not mean a second account system. Tenant isolation is enforced by the query builders, not by convention.
The official sentry_flutter package, unchanged, with one line different. Nothing from the commercial or FSL licensed Sentry backend is involved. The full walkthrough for both platforms is in the docs: Flutter and Next.js, with moving from Sentry beside them.
It starts with a production and a development environment, and issues one DSN per environment. Keys can be rotated and revoked, and a revoked key stops working on the next request rather than the next deploy.
Into SentryFlutter.init in your main(), before runApp. The SDK folds the path in front of the project id into a prefix, which is how ingest and the control plane share one hostname.
Trigger an error in debug. The issue shows up in the list within a second or two, with the trace, the breadcrumbs that led to it and the device it came from.
await SentryFlutter.init(
(options) {
options.dsn = 'https://<public key>@monitor.unrealops.ai/ingest/<project>';
options.environment = 'production';
options.release = 'com.example.app@1.4.2+31';
},
appRunner: () => runApp(const MyApp()),
);Published before there is any way to pay them, because a price argued with early is cheaper to change than one defended after launch. The free plan is open and works. The paid ones are prices rather than purchases: card payments are not switched on yet.
Free
Enough of the real product to judge it, including the part that makes it worth having.
Open. Sign up and the next screen has your DSN on it.
$13per month
One developer, or one small team shipping a handful of things.
Not purchasable yet. Card payments are not switched on.
$39per month
A studio or agency carrying other people's apps as well as its own.
Not purchasable yet. Card payments are not switched on.
About $79per month, later
The tier above Studio, for when ten projects stops being enough. It comes after launch.
Not a tier you can pick. It is what comes next, not what exists.
This is the difference worth having. At your monthly limit ingest refuses further events in the way the SDK already understands, the client stops sending, and every refusal is counted and shown on the usage screen. Nothing keeps accepting events and settles up afterwards, so there is no overage rate to look up and no invoice you did not expect. If you would rather be billed than capped, this is the wrong product and that is a fair reason to use something else.
The event allowance on every tier is pooled across your whole organization, not divided per project. Five thousand events on the free tier is five thousand across everything you run. A quiet project does not waste an allocation it never used, and a noisy one does not need its own.
Readable traces are the product, not the upsell. Putting them behind the first paid tier would mean a free account never sees what Monitor actually does, so symbolication is included at Developer and stays there.
Readable traces need a build's debug files, and those are the one thing on this page that does not reset with the month, so every tier now states how many it holds. When the allowance is full, uploading a new release deletes the oldest release's symbols to make room. The build you just shipped always resolves, and an older one stops. An upload is only refused if a single release is larger than the whole allowance, and then the message says what that release weighed and what your tier holds. A smaller tier keeps fewer releases of history, not less of the product.
There is no separate line for either and there is not going to be one, because what this deployment is short of is one thing and a second allowance would be a second number to keep in step with the first. A transaction costs one event. Ten log lines cost one event, which is the ratio of what the two cost to store rather than a round number. Between them they may take at most two fifths of a month, so turning tracing on cannot leave you at the end of the month with no crash reports, and the ceiling is released day by day rather than all on the first, so a client sampling everything cannot spend the month in an afternoon.
Paid tiers billed yearly work out to roughly ten months of the monthly price for twelve months of service. That is the intent rather than a button, because there is no billing to press it in.
Billing is the last unbuilt piece. Signing up for the free plan takes one form and ends on a screen with your DSN on it; paying for a bigger one is what is still missing. These prices are published early so you can tell us they are wrong while changing them is still free.
A monitoring tool that oversells itself is worse than no monitoring tool, because you stop checking the thing you believe is watching.
Signing up works and the free plan is real: one project, a DSN in a minute, and the ceilings above enforced. Card payments are not switched on, so Solo and Studio are prices rather than things you can buy today, and the plan picker says so instead of showing a button that fails. Nothing about a free account waits on that being fixed.
Planned after Next.js, and neither has a line written. Being next on the list is not a blocker for anything already shipped above it.
Email, Slack and signed webhooks all work, and all three run off the same decision. What does not exist is an on call rota, an escalation policy or anything that phones a person, so if a notification needs to reach somebody at three in the morning, the thing that does that is still whatever you already use.
Both were assessed and neither ships. One ten minute replay costs about what 390 stored events cost, and roughly 1,500 of them would fill Monitor's whole storage slice; but the deciding argument is not the money. A stack trace describes a program, a replay records a person's screen, and that person is your user, who never agreed to anything with us. Profiling is a different no: its volume is affordable and its capture path needs a header on your own responses, works in one browser family and switches itself off silently, so nobody here can prove it works. An SDK sending either is answered so it stops retrying, the items are counted where you can see them, and nothing is stored. If you need replay, mirror to a Sentry DSN and keep replay there.
The dashboard reads an internal control plane API that is not documented or versioned for anybody outside it, and there is no export or download. Deleting a project or an account does take its rows with it, which is the half of this that is built.
A crash loop in one app produces events as fast as the device can restart. An unbounded ingest turns that into an unbounded bill within hours, which is the failure mode that makes people turn monitoring off. It is also why a plan here stops rather than billing you: the ceiling is not a policy written on the pricing page, it is the code path in front of ingest.
Both ceilings are checked before an envelope is read or stored, so an event over the line costs a lookup and nothing else.
Over a ceiling, ingest answers 429 with Retry-After and X-Sentry-Rate-Limits. The SDK honours both, which is the part that saves money: we stop paying to say no.
Every refusal is counted against a reason and shown on the usage screen, so the number of events you did not keep is a fact rather than a guess.