Terms and billing
What this service is, what it may be used for, and what happens when you stop using it. Written plainly, because the alternative was copying somebody else's contract and hoping.
Last read against the code on 29 August 2026. Written by the person who wrote the software, from the software. No lawyer has reviewed it, and it contains no legal terms that one would have written.
What the service is
Stated narrowly, because the narrowness is deliberate.
Unreal Ops Monitor receives crash and error reports from applications you control, groups identical faults into issues, resolves stack traces where you have uploaded the build's debug artifacts, tracks which release a fault started in, and emails you when something is new, regressed or spiking. That is the whole of it. It is not a log store, a metrics system, an analytics product, an uptime monitor or a system of record, and the things it deliberately does not do are listed on service limitations.
The service is provided by Travis Carlton, an individual based in Idaho, United States, trading as Unreal Ops. An LLC is intended and this line changes to name it when it exists. There is no company registration number, VAT number or registered address published here because that decision has not been made.
Your account
Who may have one, and what you are responsible for.
- One account is one person, identified by an email address. You are responsible for what is done with your credentials, and Monitor stores a scrypt hash of your password rather than the password.
- An organization is the billing and quota boundary. Its owner can add projects up to the plan's limit, invite members, and delete everything.
- Your project's DSN is not a secret. It ships inside your application by design and the key inside it can only write events, never read them. Your upload token is a secret, it belongs in a CI secret rather than a repository, and rotating the project key rotates it.
- Minimum age and eligibility: [to decide, and to state before signup is unrestricted].
Acceptable use
Short, and each line is here because breaking it would cost somebody else.
- Send events from applications you control. Pointing somebody else's application at your project, or using an ingest key you were not given, is not use of this service.
- Do not use ingest as general storage. It accepts a crash report shaped payload and everything else is discarded, but deliberately shovelling data through it to have it held is a misuse of a shared database that other people's work depends on.
- Do not attempt to reach another tenant's data. Isolation is enforced structurally rather than by convention, and probing it is not a bug hunt this service has invited. If you find a way through, report it: see support and incidents.
- Think about what your crash reports carry. You decide what your SDK sends. Sending data you are not entitled to hold, or that you would not want in a third party's database, is your decision and not one Monitor can detect. The specifics are on privacy.
- Nothing illegal, and nothing that makes this a target. Stated once, meant plainly, and not expanded into a page of categories.
What happens if you break one of these: an operator can refuse one organization's ingest without deploying, and can delete an organization. There is no warning process, appeal process or notice period written down, and inventing one here would be pretending a procedure exists. [enforcement and notice process to decide]
Quotas refuse. They never bill.
This is the product's central promise and it is worth being exact about it.
Every plan is a set of ceilings. Past a ceiling, the thing you were trying to do is refused with a message naming the number you reached. There is no overage rate on any plan, no metered price anywhere in the code, and nothing that reports usage to a payment processor. A crash loop cannot produce an invoice, because there is no mechanism by which it could.
- Events. The monthly allowance is pooled across the organization, and there is a per minute brake on each project. Over either, ingest answers 429, the SDK stops sending, the drop is counted against a reason, and nothing is stored. Those events are lost rather than queued.
- Symbols. The pooled storage allowance evicts rather than refuses: when a new release does not fit, the oldest release's symbols are deleted until it does, oldest first, and the release being uploaded is never the one evicted. It refuses only when a single release is larger than the entire allowance, and then the message names both numbers so you can decide rather than guess. What a smaller plan buys is fewer releases of history, not a broken current build.
- Projects. Creating one past the plan's limit is refused. Existing projects are never disabled to enforce it.
- Free accounts on the deployment. Signup itself is refused once the deployment is full. See service limitations.
Underneath all of them, the database is on a plan with overages disabled, so even a ceiling being wrong ends in a failed write rather than a charge.
Billing, in the conditional, because it is not switched on
This section describes what the code does when payment is configured. Today it is not.
The published price list is Developer at no charge, Solo at $13 a month, and Studio at $39 a month, with an annual option priced at ten months of the monthly figure. An Agency tier is described elsewhere as a shape rather than a price and is deliberately not something the code can sell. Every account today is on Developer whatever those pages say, because nothing can be charged.
When billing is configured, this is what the code already does:
- Checkout happens on Stripe's own pages. Card details never reach this platform, and there is deliberately no screen here that could ask for them.
- Nothing is written when a checkout session is created. The plan is applied by Stripe's webhook, once Stripe says the money moved, so there is no ordering of failures that can leave a plan half applied.
- A verified email address is required before checkout, because the receipt goes to it.
- A failed card maps to a past due state and does not move any ceiling. Taking somebody's monitoring away part way through a month because a card expired is the sort of surprise this product exists not to spring. Stripe decides when it has given up, and that arrives as a cancellation.
- Changing a card or cancelling happens in Stripe's billing portal, reachable from the billing screen.
Refunds, proration and the invoice currency: [to decide before the first payment is taken]. Nothing in the code implements a refund today, so there is nothing here to describe honestly.
Cancelling, and what it does to data you already have
The part people are surprised by, so it gets its own heading.
Cancelling moves the organization back to the free Developer plan. It does not delete your projects and it does not delete your account.
The pooled symbol allowance shrinks the same way, though it deletes nothing on its own: the next upload that does not fit evicts the oldest releases until it does. The project limit shrinks too, but projects over the new limit keep working; you simply cannot create another.
The full mechanics of every delete, including what a soft deleted project keeps costing you and what deleting an organization takes with it, are on retention and deletion.
Ending it from this side
Because a service run by one person has to be able to say so.
This deployment may stop. If it does, the intention is to say so with enough notice to move, and to say it directly to every account rather than by taking a page down. That is an intention rather than a term: [notice period on discontinuation, to decide].
These pages will change as the product does. Every change is a change to this repository, so the honest version of "we may update these terms" is that the date at the top of each page moves and [how material changes are announced, to decide].
What is deliberately not on this page
Named, so that its absence is a decision rather than an oversight.
There is no governing law or jurisdiction clause, no arbitration clause, no warranty disclaimer, no limitation of liability, and no indemnity. Nobody involved in writing this is a lawyer, and a confident invented clause would be worse than a visible gap: it would read as though somebody had thought about it. Those four things have to be decided and then written by somebody qualified before this service takes money.
the laws of the State of Idaho, United States, without regard to its conflict of law rules, and any dispute belongs in the state or federal courts sitting in Idaho.
Said plainly, because pretending otherwise helps nobody: no lawyer has reviewed this page. There is no warranty disclaimer here and no limitation of liability, not because either was decided against but because writing one without advice would be guessing at the most consequential paragraph on the page. The service is provided as it is, it runs on free infrastructure with no guarantee, and what that actually means is written out rather than buried. This section gets drafted properly before any payment is taken
In the meantime, the practical summary is the one on service limitations: there is no service level guarantee, the events are not backed up in any way you can rely on, and Monitor must not be the only place a fact about your application exists.