Privacy Policy

1. Who we are and how to reach us

Controller: SITE QWALITY INC., a company incorporated in Delaware, United States. A Delaware corporation.

Registered postal address:

SITE QWALITY INC.
254 Chapman Rd Ste 208 # 10720
Newark, Delaware 19702
United States

Privacy and data-rights contact: privacy@siteqwality.com. This mailbox exists, it is monitored, and it is the intake point for every request described in this notice. You can also write to the postal address above.

Security contact: security@siteqwality.com. Support: support@siteqwality.com.

Data protection contact: Shawn Allen, Chief Executive Officer, ceo@siteqwality.com, is the named person accountable for data protection at Site Qwality. He is not a Data Protection Officer and we do not describe him as one. We have not appointed a statutory Data Protection Officer, and having assessed Article 37 we do not consider one to be required. We publish an accountable name anyway, because “no DPO is required” is not the same as “nobody is accountable”. For rights requests use privacy@siteqwality.com, which is monitored; the address above is for escalation.

Representative in the EU and the UK: we have not appointed a representative in the European Union under Article 27 GDPR, and we have not appointed a representative in the United Kingdom. We do not intend to appoint either. Send anything you would send to a representative to privacy@siteqwality.com, or to the postal address above. It reaches us directly and we answer it ourselves.

2. Two different roles, and why it matters to you

Site Qwality handles personal data in two distinct capacities, and your rights work differently in each.

As a controller, we decide why and how data is processed. This covers: the people who hold accounts with us, billing contacts, people who contact us, visitors to our marketing websites, domain registrant details returned by WHOIS lookups when a customer monitors a domain, and our own staff records.

As a processor, we process data on a customer’s documented instructions and the customer is the controller. This covers everything our SDK and our ingest endpoints collect on behalf of a customer: real user monitoring, session replay, logs, metrics, traces, monitoring check results, and the notification destinations a customer configures. Our Data Processing Addendum governs that processing.

If you are an end user of a website that has installed Site Qwality, we are a processor for your data. Send your request to the operator of that website. If you send it to us, we will pass it to them where it is lawful to do so, and we will tell you that we have done so.

3. What we collect, where it comes from, and why

We do not ask for and do not want special categories of data as defined in Article 9 GDPR. The Services are not designed to hold them.

4. Session replay: what it actually records

Recording rules decide which sessions are replayed, and a new application starts with some. A rule combines conditions, such as a page address, an error, a failed request, a frustration signal, a slow Core Web Vital, a custom event, an identified user, an attribute, or the device, release or environment, with the share of sessions it applies to. Every application created today starts with three rules: replay every session in which an error occurs; replay an automatic sample of sessions lasting at least 3 seconds with an interaction, at a rate set from the application’s replay quota; and capture detailed session data, without replay, for 10% of sessions. The customer can change, disable or delete any rule, and disabling or deleting a rule stops new recordings from it. The customer’s own page code can also start a recording with startReplay({ force: true }), which skips the rules and their sampling. Neither path records while consent is pending or refused, when Global Privacy Control is honoured, after an opt-out, for a user on the customer’s do-not-record list, for a session outside the application’s Observe sample, or while the application is paused. When a recording is running it captures the rendered page as the end user sees it, and we want to be exact about the defaults rather than reassuring.

A session can be recorded into memory before a rule matches. When a replay rule could still match a session, because the session falls within the rule’s sample and the rule’s device, release and environment conditions hold, the SDK starts the recorder once the application’s settings have loaded and keeps the recording in the browser’s memory. It holds the current and the previous full-snapshot interval, a new interval starting about every 60 seconds, so roughly the last 60 to 120 seconds and about 5 MB at most. If a rule then matches, or the page forces a recording, what is held is uploaded first, oldest first, and recording continues live, so a recording can begin up to about two minutes before the moment that triggered it. Otherwise nothing in that buffer is uploaded or written to storage: it is discarded when the page closes, and also when consent is withdrawn, the end user opts out, Global Privacy Control applies or recording is stopped. The SDK keeps a similar memory buffer of detailed session events, at most the last 60 seconds and 500 events, which is sent only when a rule calls for detailed capture or replay.

• Each application has a privacy level, and new applications start on Balanced. Strict masks all page text except elements the customer explicitly unmasks, masks input values, replaces images, video, audio, picture and SVG elements with placeholders, and leaves the text of clicked elements out of interaction data. Balanced masks input values and records page text, replacing email addresses, card-like numbers of 13 to 19 digits that pass the Luhn checksum, and runs of nine or more digits with asterisks. Relaxed masks input values and records page text as rendered. An application created before privacy levels existed keeps a legacy setting, in which input masking and page-text masking are separate switches and no such patterns are applied.
• Page text is not masked by default. Under Balanced and Relaxed, whatever text is rendered on the page is recorded, including text behind a login, apart from the patterns Balanced replaces. The customer can turn page-text masking on per application, or choose Strict.
• Input values are masked under every privacy level, but not necessarily on an older application. Strict, Balanced and Relaxed always mask input values. On the legacy setting, input masking is its own switch, and until a recent fix it was stored switched off on every application at the moment it was created, whether created in the dashboard or through the API. It stayed off unless someone opened the application’s privacy settings and turned it on. We have not altered the stored settings of existing applications, so an older application you have not explicitly changed or moved to a privacy level still records most form input values unmasked. Check the setting on every application you operate.
• Card numbers are not capturable where the payment field is a cross-origin element from a payment provider, because the recorder cannot see inside another origin’s frame. That is true of our own checkout.
• Element-level control uses three rrweb CSS classes, and they do three different things. Add them to the element’s class attribute, for example <div class="rr-mask">. They are class names, not HTML attributes: <div rr-mask> has no effect. Whether a class covers nested elements differs per class, so the three are described separately rather than together.
  • rr-mask replaces the text inside the element, and inside everything nested within it, with asterisks. It cascades to descendants, but it only works when the application applies no text masking of its own: no sensitive-data patterns, no mask selectors and page-text masking off, which means Relaxed or the legacy setting. Under Balanced, the default for new applications, and under Strict, the class does nothing by itself; add .rr-mask to the application’s mask selectors in its privacy settings instead. It masks text only: it does not mask input values, and it does not mask attributes such as placeholder, alt, title or aria-label, which are recorded as written apart from URL stripping.
  • rr-block stops the element being recorded at all. The recording keeps a blank placeholder of the same size and does not descend into it, so everything nested inside is covered too.
  • rr-ignore stops input events being recorded on the element that carries the class. It does not cascade. The class is read from the element that received the event and nothing walks up the tree, so <div class="rr-ignore"><input name="ssn"></div> gives that input no protection at all. The class has to be on the <input> itself. Even placed correctly it suppresses only later typing: a value already present in the field when the recording starts is still captured in the initial snapshot unless input masking is on.
• Input masking covers a fixed list of input types. When it is on, the value is replaced with one asterisk per character before it leaves the browser, for these input types: color, date, datetime-local, email, month, number, password, range, search, tel, text, time, url and week, plus <textarea> and <select>. Whatever the setting, password, email and tel inputs are always masked, an <input type="hidden"> is never recorded at all, and when input masking is off, a field whose autocomplete attribute marks it as payment-card data is left out of the recording. Two things it does not cover: a radio button or checkbox has its value string recorded unmasked alongside its checked state; and input masking never masks an element attribute, although URLs in attributes are stripped and, under Balanced and Strict, the sensitive-data patterns above are replaced in them.
• rr-unmask, data-sq-mask and data-sq-unmask do not exist. Older material of ours described element-level opt-in through those names. The recorder we run has never supported any of them, and applying them changes nothing.

5. Our legal bases

Where we rely on legitimate interests you can object at any time. See section 9.

6. Cookies, tags and tracking on our websites

Our marketing websites can load four third-party tags: Google Analytics 4, Google Ads conversion tracking, Microsoft Clarity session recording and an affiliate attribution script. We also set four first-party cookies of our own. The Cookie Policy names every one of them, along with every browser-storage key we set. It does not name the cookies those third parties set once loaded, because we cannot read those from our own source, and it says so rather than guessing.

In the European Economic Area, the United Kingdom and Gibraltar those four tags are behind a consent gate. The decision is taken on our server before the page is assembled, so for a visitor who has not agreed, the tags are not in the page at all rather than being loaded and then suppressed. The banner offers accept, reject and a per-category choice across three categories: analytics, advertising, and session recording. A Cookie preferences control at the bottom of every page reopens the choice, and withdrawing consent is as easy as giving it. Your choice is stored for 180 days, and if we change the categories or the vendors behind them we ask again rather than relying on a choice you made about something else.

Outside those countries the banner is not shown and the four tags load as they did before. A recorded refusal is honoured everywhere; an absence of one, outside the gated region, is not treated as a refusal. We would rather state that limit than describe the gate as though it were global.

The record of your consent exists only in your own browser. These are static sites with no database, so there is no server-side consent log. That is a real limitation on our ability to demonstrate a given person’s consent after the fact, and we are not going to imply we hold a ledger we do not have.

We honour Do Not Track and Global Privacy Control on our marketing websites. A DNT: 1 or Sec-GPC: 1 request header, or the equivalent browser property, is treated as a refusal in every region, and we do not show a banner on top of it. Our dashboard does not act on either signal, and our SDK acts only on Global Privacy Control. Nothing at app.siteqwality.com reads navigator.doNotTrack, Sec-GPC or navigator.globalPrivacyControl. The SDK a customer installs on their own website reads navigator.globalPrivacyControl and, when that customer’s application has the setting on, as new applications do by default, stores no anonymous visitor identifier, attaches no user identity and records no detailed session data or session replay for that browser. It does not read Do Not Track. The Cookie Policy lists what the SDK stores and when. The halves are different and we state each.

We do not sell personal data for money. Our marketing sites do load Google Ads conversion tags, and under some United States state privacy laws that counts as sharing personal information for cross-context behavioural advertising. We would rather describe it than claim an exemption.

7. How long we keep it

Retention differs sharply by category, and several stores have no automatic deletion in place today. Publishing a tidy single number would be untrue. The Data Retention page lists, for every category, either the window our systems actually enforce or a plain statement that no automatic deletion is in place yet.

Two rules apply to the windows your plan sets. A retention window runs from the moment a record is written, not from the end of a billing period. And changing your plan never shortens data that is already stored: a plan change applies forwards only, by design. Whether a window can also be lowered by a setting, rather than by a plan, is answered on the Data Retention page category by category, because the answer is not the same for every category.

8. Who we share it with

We use third-party providers to run the Services. The Subprocessors page is the authoritative, dated list. It separates providers engaged for every customer, check locations and integrations a customer switches on themselves, and vendors that only touch our website and corporate operations.

We also disclose personal data where we are legally required to, and to professional advisers where necessary. If we are ever party to a merger or acquisition, personal data would be one of the assets transferred, and we would update this notice before that took effect.

9. International transfers

Site Qwality is a United States company. Our own infrastructure is in the United States, in the AWS us-east-1 region: the transactional database, the analytics store, all object storage, and all serverless compute other than running uptime checks from a location a customer selects. There is no European Union or United Kingdom data-residency option for storage. If we bring another region into service for storage or processing, other than a check location a customer selects, we will update this notice before we do.

Check locations. HTTP uptime checks run from the check locations a customer selects for each monitor. The default is in the United States (AWS us-east-1), and browser, TLS certificate, domain expiry and DNS record checks always run there. If a customer selects a location in another country, that check runs there, on infrastructure from Amazon Web Services, Google Cloud Platform or Microsoft Azure: the monitored URL and the check’s request configuration, including any headers or credentials the customer set, are sent to that location, and the result comes back to the United States to be stored. The current locations are listed at siteqwality.com/locations/.

That sentence is scoped to our own infrastructure on purpose, because “United States only” without a qualifier would overstate it in two ways. First, our content delivery network terminates connections at edge locations that include Europe; the paragraph below says what that means. Second, some of the providers we depend on operate global networks or process outside the United States. The Subprocessors page states each provider’s location. Read that page alongside this section.

Where personal data protected by the GDPR or the UK GDPR reaches us, Standard Contractual Clauses (and the UK Addendum where required) are available through our Data Processing Addendum and on request. We do not claim certification under the EU-US Data Privacy Framework.

Our content delivery network. We operate six content delivery distributions and all six use a price class that includes European edge locations, so a request from Europe is terminated in Europe rather than in the United States. Two of the six serve public files only: the monitoring script and status-page branding images. Two serve status pages, one of ours and one on a customer’s own domain. Two front our internal staff portal, one for the interface and one that proxies staff requests to our API, which carry customer account data. None of the six has access logging enabled, so we keep no record at the edge of who requested what. The status page application itself runs on AWS Amplify behind the status page distributions, and Amplify keeps access logs for it: the visitor’s IP address, user agent and the address requested. Amplify retains those logs for as long as the application exists and does not let us shorten that. We read them only to investigate abuse or an outage. Cached copies of the content itself are held at those edge locations, including in Europe, for the lifetime of the cache.

10. Your rights

If the GDPR or the UK GDPR applies to you, you have the rights below. We answer within one month of receiving your request. Where we have reasonable doubts about who you are we may ask for information to confirm it, and where we do, that month runs from the point we receive it. We will tell you if we need to extend by up to two further months, and why.

There is no fee. If a request is manifestly unfounded or excessive, in particular because it repeats one we have already answered, we may charge a reasonable fee reflecting the cost of answering it or decline to act, and we will explain which and why.

Send any request to privacy@siteqwality.com. Please do not use the contact form on our website for a rights request: that form is operated by a third party.

We want to be honest about how these are fulfilled today. None of them is a self-service button in the product. Each is a manual operation carried out by our staff, and the sections below say where that has practical consequences for you.

• Access (Article 15). Ask us and we will assemble a copy of the personal data we hold about you. There is no automated subject-access export in the product; we compile it by hand across our databases, object storage and our providers.
• Rectification (Article 16). An account administrator can correct a user’s name in the dashboard. An email address cannot currently be changed, by you, by an administrator or by us: the only route is to remove the user and re-invite them at the correct address, which leaves the old address reserved. If that is a problem for you, contact us and we will handle it manually.
• Erasure (Article 17). You can ask us to delete your data. Closing an account today marks the account deleted and ends access to it; it does not by itself erase every stored copy. If you want data erased rather than retained, ask us explicitly at privacy@siteqwality.com and we will carry out the deletion and confirm what was deleted and when. There is no self-service account-deletion control in the dashboard. Two limits apply. Automated database backups are retained for 7 days, so erased data can persist in a backup for up to 7 days after we delete it from live systems; we do not restore a backup in order to re-apply an erasure. And we keep billing, invoice and tax records for the period the law requires.
• Restriction (Article 18). We have no automated way to mark data as restricted while a dispute is resolved. Contact us and we will handle it manually.
• Portability (Article 20). The product exports three things to CSV today: HTTP check results (up to 50,000 rows), the monitor uptime summary, and telemetry logs (up to 10,000 rows). Nothing else is covered by a self-service export. For any other category, ask us and we will produce it.
• Objection (Article 21). You can object to processing we base on legitimate interests. You can object to direct marketing at any time and we will stop. If you are an end user of a customer’s site, our SDK gives that site opt-out and consent methods but shows no control of its own, so whether you are offered one is the operator’s decision; your objection has to go to the operator of that site, who controls whether the SDK runs at all.
• Withdrawing consent (Article 7(3)). Where we rely on consent you can withdraw it at any time. Withdrawal does not affect processing that already happened.
• Automated decision-making (Article 22). We do not carry out profiling or automated decision-making that produces legal or similarly significant effects.

If you are in California or another United States state with a comparable law, the same intake address applies and we do not discriminate against you for exercising a right.

11. Complaining to a supervisory authority

You have the right under Article 77 GDPR to lodge a complaint with a supervisory authority, in particular in the country where you live, where you work, or where you believe an infringement occurred. In the EEA, the European Data Protection Board publishes the list of national authorities. In the United Kingdom, the authority is the Information Commissioner’s Office.

You do not need to contact us first. We would like the chance to fix it, but that is your choice.

12. Children

The Services are a business product and are not directed to children under 16. We do not knowingly collect personal data from anyone under 16. We have chosen 16 rather than a lower figure because the age at which a child can consent for themselves under Article 8 of the GDPR is set by each member state and ranges from 13 to 16, so 16 is the only single number that is correct everywhere we operate.

We do not operate an age gate: there is no age check anywhere in the signup flow, and we are telling you that instead of implying one exists. If you believe a child has given us personal data, contact privacy@siteqwality.com and we will delete it.

13. Email we send you

There are two kinds, and they behave differently on purpose.

Alerts and service email. Monitor up and down notices, expiry warnings, quota notices, invitations, welcome and support mail. These carry no unsubscribe header. They exist because you or an account administrator configured them, and an alert you cannot receive is worse than no alert. The way to stop them is to remove or change the destination in the dashboard, or to close the account.

Lifecycle and marketing email. A small number of messages sent to accounts that have gone quiet carry a List-Unsubscribe header addressed to a monitored mailbox. Reply to it, or write to support@siteqwality.com, and we will stop. An earlier version of this notice promised to remove you from all correspondence on request. That was never accurate for contractual alerts and it has been removed.

For commercial email we identify ourselves accurately and do not use misleading subject lines, and we act on opt-out requests promptly.

14. How we protect it

The measures below are in place today. This list is deliberately exhaustive: where a measure is not listed here, do not assume it is in place.

• Every connection between you and the Services is encrypted. All eight of our public API domains enforce a minimum of TLS 1.2, and our websites redirect HTTP to HTTPS.
• Object storage is encrypted at rest with AES-256 using provider-managed keys, and every bucket has public access blocked on all four settings. The analytics data volume that holds telemetry, real user monitoring and replay data is encrypted. Our message queues are encrypted at rest.
• Passwords are hashed with Argon2 and never stored in plain text. A specialist identity provider holds password credentials and issues sessions. We verify email challenges, authenticator-app codes and passkeys.
• Multi-factor authentication is available through authenticator-app codes and verified passkeys. Staff portal access also requires an allowed IP address and a staff role.
• API keys are stored only as a one-way SHA-256 digest. We keep the first eight and last four characters so you can recognise a key in a list. The secret itself is never written down anywhere we can read it.
• Role-based access control, enforced from the session token rather than from a local database column.
• Mutating authenticated requests are recorded to a customer-readable audit log with actor, action, method, path, result, request IP address and user agent, including requests that were identified and then denied. The write is best-effort by design so that a logging failure can never fail your request, which means a database outage can leave a gap in the log. Two endpoints that use a mutating method only to carry a read query are exempt.
• Every Site Qwality staff administrative request is written to a separate staff audit log, including a recorded reason whenever a staff member acts inside a customer account.
• Card data never reaches our systems. It is entered into a payment element served by our payment processor on its own origin.
• Bot mitigation on the signup endpoint, and request-rate throttling on eight of our nine API gateway stages. The ninth is an abandoned test gateway that serves no part of the Services and holds no data; it has no throttle and it should be deleted.
• Queries against our transactional database use bind parameters rather than assembled SQL, with no string-concatenated SQL anywhere on that path, and every data-plane read is scoped to an account identifier as a typed value before it reaches storage.
• Deletion protection on the production database, with automated backups retained for 7 days.

We hold no security certification of our own. We have no SOC 2 report, no ISO 27001 certificate and no published penetration test. Where SOC 2 or ISO 27001 is mentioned anywhere in relation to our infrastructure, that is the certification of our infrastructure provider, not ours.

15. Personal data breaches

If a personal data breach affects data we process on a customer’s behalf, we notify that customer without undue delay and in any event within 72 hours of becoming aware of it, as set out in our Data Processing Addendum. Where we are the controller, we notify the competent supervisory authority under Article 33 and, where the breach is likely to result in a high risk to you, we notify you directly under Article 34.

An earlier version of this notice said 7 business days. That conflicted with our own contractual commitment. The commitment is 72 hours.

16. Changes to this notice

We date this notice at the top of the page. When we change it we update that date. For a change that materially affects how we handle your data, we will say so on this page rather than changing it silently.

October 2026. Section 9 now describes check locations: a customer can choose to run uptime checks from locations outside the United States, on Amazon Web Services, Google Cloud Platform or Microsoft Azure. Where results are stored has not changed.

17. Questions

Write to privacy@siteqwality.com. Please do not use the contact form on our website for anything involving your personal data: it is operated by a third party, and once you load it, it runs in a frame from that vendor rather than on our page. Section 3 describes it.