Rebase (Rebase Technologies Ltd, a company registered in England and Wales (Company No. 17380046), “Rebase”, “we”, “us”) provides a widget a business adds to its website so its customers can send reports, and a dashboard where its team reviews reports, requests packets and sends them to their tracker. This policy applies to rebase.dev, the widget served from cdn.rebase.dev, and our API at api.rebase.dev.
For personal data processed on behalf of our customers (the reports and packets their own customers send through the widget), the customer is the data controller and Rebase acts as a processor under our Data Processing Addendum. For our own website visitors, account holders and the business contacts we reach out to, Rebase is the controller.
1. Data we collect
Account & profile data
When you create an account or join a workspace, we store your email address, name, workspace role and sign-in details. During setup we also ask your job role, your company’s size and how you heard about Rebase. You sign in with a one-time code sent to your email; we do not store passwords.
Reports and captured details (from the widget)
When someone sends a report through the widget, Rebase captures context to help the team reproduce and fix the problem:
- The element the person highlights, if any: its tag, id, classes, label and a short masked HTML excerpt;
- A screenshot of the visible viewport;
- Console messages (errors and warnings) and recent network request metadata (URL, method, status, timing);
- Page URL/path, referrer, and a recent trail of interactions (clicks, inputs, navigation);
- Browser, operating system, viewport, language, timezone, and connection information;
- Technical context such as the framework, script addresses and release version;
- If the workspace turns on Replay, a recording of page changes (not a video) from about the last minute before the report, which the person can remove before sending;
- Optional identity supplied by the host application, treated as unverified report metadata.
Privacy by default. Before anything leaves the page, the widget masks every typed value by default, and password, payment-card, one-time-code, phone and hidden fields are always masked. It also masks any element marked with data-rebase-mask. Replays hide page text and images unless the workspace chooses to show them, and a website can make Replay wait for visitor consent. URLs, request headers, and common secrets are scrubbed. Request bodies are off by default; bounded, scrubbed excerpts of failed responses may be captured. Customers are responsible for configuring additional masking for sensitive fields on their site.
Packets
Packets are on by default for each website, and a workspace can turn them off. While they are on, the widget keeps scrubbed details of recent visits in that website’s browser storage for up to 24 hours, within a 5 MiB limit per website origin. Visits are separated across tabs and known account changes. Storage can disappear sooner, and a crash can lose details that were not yet saved.
When a customer opens a packet link, they see what would be shared, and nothing is sent until they choose to share it. No Rebase account is needed. If several visits match, they choose which to share. If they choose to try again instead, that attempt can be recorded, and its replay is sent only if they choose to share with replay. If history is missing, you can open the link in the original browser or explicitly start, share or cancel a fresh attempt. The collection tab does not supply a new screenshot as evidence of the earlier problem.
A packet keeps the customer’s description, its support conversation reference and what was shared, under the same retention as reports. Sharing alone does not start AI or create a tracker issue; a teammate decides whether to send it to the tracker as an issue or a comment. Teammates request packets from the Inbox, from Slack with/rebase, or by mentioning Rebase on a GitHub or Linear issue. When a team connects Slack, Rebase stores its workspace connection and explicitly linked account identifiers. Thread cards contain status and actions; private views opened by authorized staff may contain diagnostic summaries processed by Slack. Collection metrics contain counts and timing, without evidence content or sharing grants.
Billing data
Payments are processed by Stripe. Rebase stores subscription status and plan, but never receives or stores full payment-card numbers.
Each card can start one free trial. To enforce this, we keep a one-way hash of the card’s Stripe fingerprint, made with a secret key, and the date of its first trial, based on our legitimate interest in preventing trial abuse. While that first trial runs we also keep the organisation’s id and its Stripe subscription id with it. Once the trial ends, or the organisation is deleted, only the hash and the date remain, including after your account or workspace is deleted. We keep the hash and date for 3 years from the first trial, then delete them. A data-deletion request doesn’t remove this record, because deleting it would let the card start another free trial. The record holds no card number or other card details. Those stay with Stripe.
Website & log data
Like most services, our servers record technical logs (IP address, user agent, timestamps) for security, debugging, and abuse prevention. Our marketing website also uses Google Analytics to understand aggregate usage; see our Cookie Policy. When you sign up, your new organisation records which page of our website your visit started on, the site that linked to it and any campaign tags in that link, never who you are or what else you viewed. We use this under our legitimate interest in learning which pages and communities bring us customers.
Product usage data
To understand and improve the product, we collect usage analytics: on our marketing website only with your consent (see the Cookie Policy), and, when you are signed in to the hosted app, service events associated with your account email, for example completing a setup step or sending a first report. We use these under our legitimate interest in understanding how the product is used, to measure activation and improve onboarding. These events describe your use of Rebase itself and never include your Customer Data or the content of reports.
Sales & CRM data
When you sign up, we store your name, email, company, job role, company size, how you heard about us, your plan and your setup progress in our CRM (HubSpot) to manage the relationship, and may derive company context from your email domain. We do this under our legitimate interest in operating a business-to-business service; you can ask us to remove your details at any time via support@rebase.dev.
Business contacts
We contact people at companies that may find Rebase useful, at their work addresses only. If we contact you this way, we hold your name, work email, job title, company and public profile URL, and notes from our calls or your replies. Our outreach emails come from addresses at getrebase.dev, a domain we use only for outreach about Rebase.
We get these details from Apollo.io, LinkedIn and public websites, such as company help centres and public code repositories. We use them under our legitimate interest in telling businesses about a product relevant to their work. The providers we use for this outreach, including Apollo.io, are listed on our Subprocessors page. We keep these details for 12 months from our last contact, unless you become a customer.
You can opt out at any time. Reply to any of our emails, or write to support@rebase.dev, and we will stop contacting you. This right to object to direct marketing always applies. We keep only a minimal record that you opted out, so we don’t contact you again. Your other rights, and how to complain to the ICO, are in Your rights.
Booking a call
If you book a call with us, Cal.com handles the booking. It holds your name, email address and anything you add to the booking, and passes them to us so we can meet you. We use these details to arrange and hold the call you asked for. Cal.com is listed on our Subprocessors page.
Past job applicants
If you applied for a role in the past, your application was emailed to our hiring team and is not stored in our product databases. We keep it only as long as that hiring process needs.
2. How we use data
- To provide, operate, and secure the widget, API, and dashboard;
- To send reports and packets to the tracker you connect, and to run AI triage where it is on;
- To send emails such as report activity, a weekly summary and setup tips, which you can turn off;
- To process payments and manage subscriptions;
- To prevent fraud and abuse and to comply with legal obligations.
We do not sell personal data, and we do not use customer reports to train machine-learning models. See our AI Policy for how AI features work.
3. Legal bases (EEA/UK)
Where GDPR/UK GDPR applies, we rely on: performance of a contract (providing the service), legitimate interests (securing and improving the service, and preventing free-trial abuse), consent (where required, e.g. optional communications), and compliance with legal obligations.
4. Sharing & subprocessors
We share data with vetted service providers who process it on our behalf — for cloud hosting and storage, payment processing, email delivery and hosting, and the issue trackers you choose to connect. A current list is on our Subprocessors page. We may also disclose data to comply with law or to protect our rights, and in connection with a merger or acquisition (with notice where required).
5. Hosting & international transfers
Rebase’s application servers, database, and screenshot and replay storage are hosted in the United Kingdom (London) on DigitalOcean. The website and dashboard are served from Cloudflare’s global edge network, which also provides edge delivery and TLS for the API and widget. Transactional email is sent from the EEA (Ireland). Some of our subprocessors (payment processing by Stripe, AI triage by OpenAI, error monitoring by Sentry, analytics by Google, email hosting by Google Workspace, CRM by HubSpot, business contact data by Apollo.io and call booking by Cal.com) process data in the United States; the full list is on our Subprocessors page. Where personal data leaves the UK/EEA for a country without an adequacy decision, we rely on appropriate safeguards such as the EU Standard Contractual Clauses and the UK Addendum.
6. Data retention
Account data is retained while your account is active. Screenshots, replays and captured diagnostic details are kept for the workspace plan’s evidence history (30 days on Starter, 90 on Growth and 180 on Scale; 7 days without an active plan) and then deleted. Replays are kept for at most 30 days. A report keeps its title, description, page address, environment, release, AI-suggested title and follow-up question, and a packet its description, support reference and Slack context, as workspace data until the workspace deletes it. Deleting a report or packet removes it from Rebase. Database backups are kept for up to 60 days, so a deleted item can remain in a backup until that backup expires, and deleted files can be recovered for 7 days. The card hash and date used to limit free trials are kept for 3 years from the first trial, including after your account or workspace is deleted or you make a data-deletion request, as described under Billing data. Logs are retained for a limited period and then rotated.
7. Security
Data is encrypted in transit (TLS) and at rest. Screenshots and replays are stored in private object storage and shown only to signed-in members of the workspace, or to a coding agent using an access token a teammate creates; replays are shown only in the dashboard. When a workspace connects an issue tracker, the issues Rebase creates there include the report’s screenshot and captured details. Access to production systems is restricted and authentication tokens are short-lived and rotated.
8. Your rights
Depending on your location, you may have rights to access, correct, delete, export, or restrict the processing of your personal data, and to object or withdraw consent. To exercise these rights, contact support@rebase.dev. If we process data on behalf of a customer, we will refer your request to that customer. You may also lodge a complaint with your local supervisory authority. In the UK, that is the Information Commissioner’s Office (ico.org.uk).
9. Children
Rebase is not directed to children and is not intended for anyone under 16. We do not knowingly collect data from children.
10. Changes
We may update this policy from time to time. Material changes will be posted here with a new “Updated” date.
11. Contact
Questions? Email support@rebase.dev or write to Rebase Technologies Ltd, 71-75 Shelton Street, London, Greater London, WC2H 9JQ.