Support and incidents

Unreal Ops is built and operated by one person. There is nobody to escalate to, nobody on call, and no phone number. Messages are read when that person is awake and not mid flight, and answered in the order they arrive unless one of them is somebody's production being down.

Send a message from the support form rather than an email address. It reaches the same one person, and it attaches what a bare address never could: your organization, project, plan, and whether either is currently over a ceiling or has a kill switch armed. Target response time: [to decide, and to be one you can keep]. That is not a placeholder for something that exists elsewhere; it is a decision that has not been made, and putting a plausible number here would be inventing a commitment.

There is no paid support tier that changes any of this today. Priority support appears on a published price list, and on this deployment nothing can be bought, so nobody has it.

• Alert email, per issue. On a new issue, on a regression, and on a spike, to the addresses you list in the project's alert settings. The subject alone says what broke. The body answers what, where, how many people and which release, and the stack trace is behind the link rather than in your mailbox. Alerting caps itself hard so that four hundred crashes cost one email: an hour of cooldown per issue, a minute of burst brake per project, ten an hour and forty a day.
• Slack. The same alerts, in a channel, if you paste an incoming webhook url into the project settings. Slack and mail fire on the same decision and neither can answer for the other, so both arriving is normal and one being down never silences the other.
• A daily check that goes looking. Once a day, at 05:20 UTC, Monitor compares what each project stored this month against what it was refused. Past a hundred refusals and a third of everything, or past five internal errors, it tells you once, through the same channels your alerts use. It stays quiet on the following days while the condition is still true, and re-arms itself when the condition stops, so recovery is what makes the next failure news again. This exists because one project on this deployment stored 64 events and was refused 29,219 in a month, every number was already in the database the whole time, and it was found by chance.
• The usage screen. Your organization's pool, each project's share of it, every refusal broken down by reason, and symbol storage next to the same figures. It separates "refused, and you lost data" from "this platform has no product for that item type", because those read identically as a single number and are opposite situations.

Your SDK also knows. Every refusal is a 429 carrying Retry-After and X-Sentry-Rate-Limits, which the Sentry SDKs already understand: the client stops sending and records the drop on its side too.

What exists instead is on the operator's side. Failures of the nightly sweeper and the health check are recorded and reported, capacity against the shared database budget is watched daily, and Monitor watches its own application through the same public SDK a customer uses, pointed at its own ingest, so a break in the dashboard shows up as an issue in a project. None of that reaches you directly today.

Where incidents will be communicated when there is somewhere to put them: [incident channel to decide: a status page, a mailing list, or direct mail to every account]. Until that is decided, the honest answer is that you will hear from tc@devtc.pro and only if it is noticed.

Nothing at this end buffers, queues or backfills. If ingest is down, refusing, or deliberately stopped, the events your app tried to send in that window are gone. The SDK holds them in its own transport queue for a short time and then drops them. There is no replay, no catch up job and no way to ask for them afterwards.

Deliberate stops are part of this. There are switches an operator can flip without deploying: refuse all ingest across the deployment, refuse one organization, or stop the background jobs. There is also an automatic breaker that can refuse a single project when it can prove that project is at fault, which is how a feedback loop gets contained rather than shipped a fix for hours later. Everything refused while one of those is armed is counted, and counted as a deliberate loss rather than an accident, so the usage screen can tell you which it was. It is still lost.

The one thing that keeps working during an incident here is your own upstream, if you configured a mirror. Events forwarded to a Sentry DSN you named are sent independently of anything Monitor does with them, and Monitor being unavailable is exactly the case that makes running both for a while worth it.

• Nothing is arriving. Start at troubleshooting, which is arranged by symptom rather than by cause, because that is how you arrive.
• Stacks are unreadable. Readable stack traces covers what each build has to upload and what each frame's label means. A frame that could not be resolved names the artifact it wanted.
• Usage says things were refused. The usage screen names the reason for every drop, and the difference between a refusal and an item type this platform has no product for is the difference between a problem and a non event.

• The organization and project name, and the environment.
• An approximate time, with a timezone, and what you expected to see.
• The issue link if there is one. It is a path to an issue id and reading it needs an account, so it is safe to send.
• Which SDK and version, and whether the build was a release build.
• Never a password, an upload token or a session cookie. Nothing that can be answered needs one.

If you find a way to read another tenant's data, to make ingest accept an envelope for a project you do not own, or to reach the cron endpoints, report it directly and privately to tc@devtc.pro rather than demonstrating it further. There is no bug bounty and no reward programme, and pretending otherwise would be worse than saying so.

Tenant isolation is enforced structurally rather than by convention: statements against tenant tables can only be built by scoped builders, a scope can only be minted from a credential, and the executor rechecks the predicate before every statement. That is a design rather than a guarantee, and a report that it is wrong somewhere is the most valuable message this address can receive.

• No guaranteed response time, no out of hours cover and nothing that wakes anybody up.
• No data recovery. Events past their retention, past a refusal or past a purge are not recoverable, and the provider's point in time recovery window is short. See service limitations.
• No help debugging your application. Monitor will tell you the file and the line, and what you do about it is yours.
• No onboarding call, migration service or account management, though if you want an app pointed at this before signup is unrestricted, asking is the way that happens today.