What Boosthis collects inside your app
When you install Boosthis, our software runs inside your application: it measures how your own code behaves and sends readings back to us. That makes us a third party processing data inside your product, and it is something your users can reasonably expect your privacy policy to mention.
Only we can say accurately what our software does inside your app, so this page says it — what the kit sends, what it never sends, what changes when you switch something on, where it is processed, how long it is kept, and what happens when one of your users asks to be forgotten. At the bottom there is a paragraph you can paste into your own policy.
This page describes how our software behaves. It does not tell you what your own policy needs to say — that is yours to decide, with your own advisers. Everything here restates our published Privacy Policy in the words your reader needs, and a check fails our build if the two ever describe different data.
What the kit sends
Every registered install sends these, in every runtime, whatever else you have switched on. "Registered" means a Boosthis project key is configured — an install with no key never sends anything at all.
- A random install identifier — A UUID generated on the machine your app runs on, the first time it registers. It is not derived from, or linked to, a device, a user, an IP address, a hostname or an account.
- Buckets describing a recurring performance problem — When the same performance pattern recurs, the kit sends the kind of problem it detected, a three-level severity bucket and a coarse occurrence-count bucket. The screen or route name is deliberately dropped.
- Buckets describing when one of those problems improves — When a tracked problem gets better, the kit sends the kind of rule and the before-and-after rating bucket — good, needs-work or poor. It is the fact that something improved, never the change that improved it.
- Error types with a redacted code location — When your app hits an uncaught error, the kit sends the error type, a redacted code location (function name, file basename and line number — never a path, URL, argument or value), a hash derived only from those code-defined tokens, and how many times it recurred.
- Anonymous notes about patterns we have no rule for yet — When the kit meets a slow or buggy pattern it has no rule for, it may send the runtime, a coarse category, a severity bucket, a timing bucket, a hash and a recurrence count. Buckets and a hash — never a screen name, a value or your source.
- The kit version and the runtime it runs in — For example, the Boosthis package version together with the language runtime, so a reading can be interpreted against the version that took it.
What changes if you switch something on
These are the claims that are true for some customers and false for others. Check each one against your own app before you repeat it to your users.
If you switched on full performance details
Depends on you Off unless your code calls enableTelemetry(). It stops the moment you call disableTelemetry().
- The route or function label — The code-defined name of the route or function you instrumented — for example /api/users or get_orders. Our guard refuses to transmit the field if it contains an email address, IP, token, phone number or other identifier, and drops the whole sample instead. If you put user content in your route names, this is the field it would reach.
- How long it took — A duration in milliseconds for that route or function.
- A rating bucket for the timing — One of good, needs-work or poor.
- A rule identifier, when you attached one — If you attached a Boosthis rule to the sample, the identifier of that rule.
How to tell: Search your own source for enableTelemetry (or enable_telemetry). If it is not called, these per-route fields are not being sent. (The meter snapshot below has a second switch of its own, so check that separately.)
If full performance details OR meter sharing is switched on
Depends on you Either switch uploads it: your code calling enableTelemetry(), or you switching on meter sharing for that project so a connected AI can read your live numbers. disableTelemetry(), erasing the install, and BOOSTHIS_DISABLED=1 each stop it.
- The numbers behind the health meters — One small snapshot of your dashboard meters — the boot ladder, Speed, Smoothness, Scroll, Stability, Render, Frustration and Idle, plus the runtime-specific ones such as event-loop lag, memory growth and worker health. Only the latest snapshot per project is kept. New meters ship regularly, and every one of them stays inside the three things below.
- A score and a rating bucket for each meter — A score from 0 to 100, and one of good, needs-work or poor. Even the one-line caption a kit computes for its own on-device display is dropped at the door and rebuilt on our side from the numbers.
- Plain numbers — counts, timings, rates and sizes — For example: milliseconds spent loading modules before startup finished, kilobytes of memory growth per request, worker restarts per hour, queue and lock waits, garbage-collection pauses, pending task counts, or how many errors were logged in the window. The server keeps a fixed allowlist of numeric meter fields, drops any field not on it, and rejects any allowlisted field whose value is not a plain number.
- Nothing else in the snapshot — No message text, no log lines, no file, module, thread, worker or command names, no source code, no values from your app, and nothing about your users.
- An error meter counts errors; it never carries the log — We receive how many errors your app logged and survived during the window, and the rate per hour — never the message, the log line, the logger name, the level, the stack, or any value.
- A subprocess meter counts spawns; it never carries the command — We receive how many subprocesses were spawned per minute and the total for the window — never the command line, its arguments, its path, its environment, or its output. Thread, worker, handle, timer, module and descriptor meters work the same way: only how many, never their names.
How to tell: Two things to check, not one: search your own source for enableTelemetry (or enable_telemetry), and open the project in your Boosthis dashboard to see whether meter sharing is on. Either one on means the snapshot is being sent; only with both off is it not.
If you switched a project into detailed crash mode
Depends on you Off unless you turn it on for a specific project from your Boosthis dashboard.
- The first line of an error message — Only the first line, and only if it passes our guard — if anything in it looks identifier-shaped (an email, token, IP, phone number), the entire line is dropped rather than partly redacted. If your error messages quote user input, this is the field it would reach.
- Sanitized stack frames — Each frame reduced to a function name, a file basename and a line or column. Absolute paths, URLs, query strings, arguments and local variables are never included.
How to tell: Open the project in your Boosthis dashboard: detailed crash mode is a per-project setting shown there.
If your app is a React Native app
Depends on you Decided by which kit you installed, not by a setting. Only the React Native kit sends it.
- A daily-rotating reach tag — A small random value the device mints fresh each calendar day, never derived from the device, the user, an account or the install ID. We fold it into a coarse estimate of roughly how many distinct devices hit the same issue this week and never store the tag itself. Because it rotates daily it cannot follow a device across days.
How to tell: It applies if you installed the React Native kit in a mobile app; no other runtime sends it.
What it never sends
None of these leave your application, under any setting. A denylist enforces it on the device and again on our server, and a batch that trips either one is rejected whole.
- IP addresses — Never as part of telemetry, and never used to identify anyone or joined to telemetry. Like nearly every web service our server does briefly count requests per connecting address for rate limiting, and keeps short-lived operational request logs; both expire automatically.
- Anything that identifies one of your users — User IDs, email addresses, names, phone numbers, postal addresses, device IDs or any other identifier. A denylist blocks them on the device and again on our server, and a batch that trips it is rejected whole.
- The contents of requests and responses — Request bodies, response bodies, query strings and headers are never read or sent.
- Raw stack traces, raw error messages and log lines — A crash report carries a redacted code location and an error type — and, only in detailed crash mode, a first line that passed the guard. A meter that watches logged errors records how many and how often, never the line, the message, the logger or the level.
- Anything about the processes your app spawns — Command lines, arguments, environments and output are never sent. The subprocess meter records only how many spawns happened and how often.
- The names of the things the meters count — Threads, workers, modules, handles, timers, files, pools and queues are counted, never named. A meter reports how many and how long, never which.
- Your source code and your environment — Source code, file paths, hostnames and environment variables are never read or sent.
- Anything your users see or say — Screen contents, screenshots, video and audio are never captured.
Where it is processed
Readings from your app are held on our infrastructure, which runs outside the Kingdom of Saudi Arabia:
- Replit — hosting and the managed PostgreSQL database, and the AI gateway in front of OpenAI. Runs in the United States.
- Google Cloud — backup storage — the routine encrypted database backups described under Retention. Runs in the United States.
These are the companies that hold what the kit sends. The full list of every company that can see any of your data — including the payment and email providers, which never receive telemetry — is in our Privacy Policy.
How long it is kept
- Performance samples and traces — Kept while the install keeps reporting. Erasing the install deletes them immediately, and they are deleted after the 60-day countdown that follows a revoked or suspended key.
- Meter snapshots — Only the latest snapshot per project is kept — each upload replaces the previous one.
- Issue, fix and crash signals — Kept while the install keeps reporting, one row per install and signature. If you erase the install they are not deleted but permanently de-identified: the install identifier is replaced with a random anonymous key, and any detailed crash fields are removed, so what remains cannot be traced back to your app.
- Backups — Routine backups of our operational database are kept for up to 30 days and rotate out automatically, so erased data disappears from them as they rotate.
How one of your users can be forgotten
Your users' data is not the data we hold — and that is the honest answer to give a reviewer who asks. The kit sends nothing that identifies a person: no user IDs, no IP addresses, no request contents, nothing from a screen. So there is no per-user record here to find, export or delete, because nothing we store is keyed to one of your users in the first place.
What exists is per install — your application, not your users. You can stop it or erase it yourself at any time, without asking us:
- Stop the optional details — disableTelemetry() stops per-route samples and meter snapshots, and leaves the always-on signals running.
- Stop everything, without a code change — Setting BOOSTHIS_DISABLED=1 in your app's environment silences the whole kit, always-on signals included. It wins over every other setting.
- Erase everything we hold for that install — boosthis telemetry forget deletes the install row and every sample, snapshot, trace and alert tied to it, permanently de-identifies the learning signals, and deletes the local config file. It is immediate and irreversible.
Erasing an install is immediate and irreversible. Signals already learned from are not deleted but permanently de-identified: the install identifier is replaced with a random key, so what remains cannot be traced back to your app.
Words you can paste into your privacy policy
A short block naming us as a provider, describing the data, and linking to our full disclosure. Paste the first box; then add each extra sentence only where its condition is true for your app.
True for every app that has Boosthis installed and registered. Start here:
Performance and error monitoring (Boosthis). We use Boosthis, a developer tool operated by Veqtara Tech Company (Rabwa District, Al Noaim Street, Riyadh, Saudi Arabia), to measure how this application performs and to find errors in it. Boosthis software runs inside the application and sends it technical measurements about the application itself: a random installation identifier that is not derived from any device or person; coarse buckets describing a recurring performance problem; coarse buckets describing when one of those problems improves; the type of an error together with a redacted code location (function name, file name and line); an anonymous note about a slow or buggy pattern Boosthis has no rule for yet; and the Boosthis version and the runtime it is running in. It does not receive IP addresses; user IDs, email addresses, names, phone numbers, postal addresses or device IDs; request or response bodies, query strings or headers; raw stack traces, raw error messages or log lines; the command lines, arguments, environments or output of processes the application spawns; the names of the things its meters count — threads, workers, modules, files or queues; source code, file paths, hostnames or environment variables; and screen contents, screenshots, video or audio. The measurements are processed and stored by Replit and Google Cloud in the United States. Measurements are kept while the application keeps reporting, and we can erase everything Boosthis holds for this application at any time. Boosthis's own statement of what it collects is at https://www.boosthis.com/docs/what-boosthis-collects.
Add this sentence to the paragraph above only if this is true of your app — pasted otherwise, it describes data you are not sending:
This application also sends Boosthis the code-defined name of the route or function being measured, how long it took in milliseconds, and a good / needs-work / poor rating.
Add this sentence to the paragraph above only if this is true of your app — pasted otherwise, it describes data you are not sending:
This application also sends Boosthis the numbers behind its health meters: a score out of 100 and a good / needs-work / poor rating per meter, plus plain measurements — counts, timings, rates, percentages and sizes — with no text of any kind alongside those meter numbers.
Add this sentence to the paragraph above only if this is true of your app — pasted otherwise, it describes data you are not sending:
Crash reports from this application also include the first line of the error message (dropped entirely if it looks like it contains personal data) and stack frames reduced to a function name, file name and line.
Add this sentence to the paragraph above only if this is true of your app — pasted otherwise, it describes data you are not sending:
On mobile, the application also sends a random tag that changes every day and is never derived from the device or any account, used only to estimate roughly how many devices hit the same problem.
Adapt the wording to fit your own policy — the point is that the facts in it are ours to state and are accurate as they stand. If something here does not match what you see, write to support@boosthis.com and we will correct it.
If your reviewer wants more
- Our full Privacy Policy — the same facts in our own terms, including every company that can see any of your data.
- The help centre, for what Boosthis measures and how it is installed.
- support@boosthis.com — a question about your own deployment reaches a person.