Privacy policy

The short version

• We store what a bug report needs: the message, the screenshot the visitor chose to attach, browser diagnostics, and the page the report came from.
• We never capture request or response bodies, headers, cookies, keystrokes, or form input, and we do not record sessions. We do capture the full page URL and your own console output verbatim, so a secret your page puts in either of those reaches us — see the exact limits of that claim.
• We do not sell data, we do not share it for advertising, and we run no third-party analytics or advertising trackers on supportshot.com.
• You can delete any ticket, any project, or your whole workspace from the dashboard yourself — the last of those erases everything we hold for it, and it happens the moment you confirm, not within 30 days. Two things outlive it, each for at most 14 days: a backup taken before you pressed the button, and — only if the workspace was paying — the Stripe identifiers we keep just long enough to cancel the subscription. Both are described below.
• Questions or requests go to support@supportshot.com and a person answers them.

Who we are, and who controls what

supportshot.com and the embeddable report widget served from it are operated by 2662415 Ontario Inc., a corporation incorporated in Ontario, Canada under corporation number 2662415, registered office 408 Dundas Street South, Unit 101, Cambridge, Ontario N1R 8H7, Canada. SupportShot is that company’s product name. Where this policy says “we” it means that company, and it is the controller, the processor, and the party you or a supervisory authority would deal with. Contact: support@supportshot.com.

There are two relationships to keep straight. For your account data — your name, email, organization, subscription — we are the data controller. For the bug reports your visitors submit, you are the controller and we are your processor: it is your website, your visitors, and your decision to collect them. We process that data to provide the service and on your instructions, which in practice means the settings you choose in your dashboard.

What we collect

Account data

Your email address and a hashed password, your organization and project names, the recipient email addresses you configure, your allowed origins and widget appearance settings, and your subscription status. We keep this for as long as your account exists.

Ticket contents

Everything a visitor sends when they submit a report: the message they typed, the email address they gave or that your site supplied through identify() (with any id and name you pass), and the screenshot if they attached one — both the annotated version and the original. A screenshot is an image of what was on their screen, so it may contain personal data. The visitor decides whether to attach one and can send the report without it.

Diagnostics

Attached automatically to each ticket: the last 200 browser console entries (each message truncated to 1 kB, with a stack trace truncated to 1 kB of its own where the browser gives one) including JavaScript errors and unhandled promise rejections; the last 50 failed network requests as method, URL (truncated to 256 characters), status, duration, and timestamp; and the page URL and title, the browser family and its major version, the operating system family, viewport size, device pixel ratio, timezone, locale, and widget version.

Two things to be exact about, because the numbers above describe our widget and not our door. The ingest API accepts up to 2,000 console entries and 2,000 network entries per report and discards the rest, and it accepts the page-context object as an open set of keys rather than a fixed list, so a newer widget can add a field without older servers rejecting it. Our widget never sends more than 200 and 50, and never sends a key outside the list above; a hand-written client posting with your project key could send up to those larger limits, and what arrives is stored on the ticket and shown to you. What the widget does not collect, below, is a property of the widget in the same way.

If a hand-written client matters to your threat model, be exact about what your allowed-origins list does and does not do about it. Origin is set by the browser, and only a browser is bound by it — a client that is not a browser, which is the case the paragraph above is about, sends whatever origin it likes and is accepted on the same terms as your own site. Keep the list tight anyway: it is what stops another website from posting into your project through one of your visitors’ browsers, which is a real threat and a different one. Treat it as a filter rather than as authentication. What bounds somebody who has your key and is not using a browser is the two rate limits on the ingest API — ten submissions per minute per project and sixty per minute per source IP address, the same two counters described under Rate-limit counters below — and everything they do send lands on a ticket you can read.

The operating system is recorded as a family only — Windows, macOS, iOS, Android, Linux — with no version number, ever. The browser carries its major version and nothing finer.

What the widget never collects

• Request or response bodies and headers — so an Authorization header, a cookie header, or a JSON payload is never read and never sent. Read the next paragraph before treating that as “secrets cannot reach us”.
• Successful network requests. Only failures are recorded.
• Keystrokes, form field values, clipboard contents, cookies, localStorage, or sessionStorage.
• Session recordings, mouse trails, or any continuous background capture.

Where a secret still could reach us, and it is not the headers

Two paths carry whatever your own page puts in them, and neither is filtered:

• The page URL. We record location.href in full — path, query string and fragment, untruncated. If your application puts a session token, a password-reset token, a signed download link or an email address in a URL, it is on the ticket. The URLs of failed network requests are recorded the same way, truncated at 256 characters only because of their length, not to remove anything.
• Console output. Whatever your code passes to console.log and its siblings is converted to text as it stands and kept, up to 1 kB per entry. A debug line that prints a token, a request body, or a user record is captured exactly as it was printed. We do not scan it, redact it, or pattern-match it for secrets — a filter that catches most secrets is worse than no filter, because it invites you to rely on it.

Both are your page’s content rather than ours, which is why the honest answer is a warning and not a promise: the widget collects the console and the URL because that is what makes a bug report actionable, and it cannot tell your secret from your stack trace. Nothing is collected until a visitor presses send, and nothing is collected at all on a page where the widget is not installed — so the lever you have is which pages carry the tag.

Nothing reaches us until a visitor presses send. To be precise about what happens before that, in the order it happens: the moment our script runs it starts recording the console entries and failed requests listed above into two small buffers inside the page, in memory. That is deliberate and it is first, because the errors worth reporting are usually the ones that already happened — a widget that only started listening later would miss them. Then it makes one request to us for the project’s settings (its colour, its position, whether it is switched on), carrying the public project key and nothing about the visitor. If that request fails, or the project is switched off or unknown, the widget stops recording, puts the page’s console, fetch and XMLHttpRequest back exactly as it found them, and displays nothing at all. The buffers never leave the page: they are discarded when the visitor navigates away, and they are transmitted only as part of a report the visitor wrote and sent. The screenshot is taken at the moment they ask for one and never before.

The widget sets no cookies and stores nothing on your visitors’ devices.

Site and service logs

We do not keep per-request access logs for supportshot.com or the ingest API. The proxy that terminates every request to us has its access log switched off, so there is no per-visit record of IP address, requested URL, user agent and response status anywhere in our systems. That proxy is our own, on our own server. Nothing else stands between your visitors and it: Cloudflare, Inc. is our DNS and is not in the request path, so there is no edge network holding a copy of what we are not keeping either.

Four things are kept, and this is all of them:

• Application event logs. What the service was doing when something happened — a report arriving, a send failing, a fault being handled. This is diagnostic output, not a record of visits.
• Operational records inside those logs that can name a person. The recipient address a notification email failed to reach, the site a report was submitted from, the address a verification or password-reset mail was sent to.
• Rate-limit counters, held in the database rather than in a log. Two of them apply to bug reports: ten per minute per project, which needs no IP address, and sixty per minute per source IP address on the ingest API, applied before we know which project a report is for. The second one means the IP address a report was sent from is stored, briefly, as the key of a counter — it is never joined to a ticket, and it exists to stop one host making our servers parse an unbounded number of uploads. It is charged only when a visitor sends a report: the settings request the widget makes on every page load is not counted and not recorded, so simply loading a page that carries the widget writes nothing about the visitor anywhere. It is the only place we hold a visitor IP — the only counter anywhere in the service that is keyed on somebody who came to us through one of our customers’ sites.
• One more counter, on our own signup form, keyed on the address it was submitted from. Ten new accounts per hour per source address. It is not about visitors to our customers’ sites and never sees one: it is charged when somebody creates an account on supportshot.com, and it exists because a script created thirteen unused accounts here over two days in July 2026. The address is held as the key of an hourly counter, capped at 45 characters, never joined to the account it was charged against, and gone when the window rolls. The sign-in, password-reset and verification forms are limited on the email address instead and hold no IP at all.

We use all of it to run the service, investigate abuse, and enforce rate limits.

None of it is archived. The logs are written to files of fixed size that rotate and overwrite their own oldest lines as they fill, so a line lasts as long as it takes the lines after it to push it out — typically days, and at most 30, which is when we clear anything still sitting there. A deploy shortens that further: a replaced container takes its logs with it. Nothing copies these lines anywhere more durable first. The rate-limit counters are shorter still: a counter is deleted within hours of its window closing, by a sweep the application runs on itself.

Payment data

Card details go directly to Stripe and never touch our servers. We store the Stripe customer and subscription identifiers, your plan, and your billing history as Stripe reports it.

How we use it

• To store your tickets and show them to you in your dashboard.
• To email each report to the recipients you configured.
• To send transactional email: address verification, password resets, and, when you exceed your plan’s ticket limit, an upgrade notice (at most once a day).
• To send an account owner a notice we are obliged to send — a personal data breach, a subprocessor change, a price change, a change to these documents. What they are, and why they have no unsubscribe, is below.
• To count tickets against your plan, enforce rate limits, and bill your subscription.
• To keep the service working and secure — debugging failures, investigating abuse, and restoring service after a fault.

We do not sell personal data, we do not share it with advertisers, and we do not use your tickets or screenshots to train machine-learning models. Staff access production data only when needed to fix a fault or answer a support request you raised.

If you are in the EEA or UK: we process account data to perform our contract with you and, for security and product improvement, on the basis of our legitimate interests. Ticket data is processed on your instructions as controller.

Wherever you are, the controller described above is the party to contact about your personal data, and support@supportshot.com reaches a person rather than a queue. Being outside the EEA or the UK does not shorten the rights set out below or the 30 days we answer in, and it does not affect your right to complain to your own supervisory authority.

The Article 28(3) terms that govern that processing are written out in our data processing agreement. It is part of the terms of service, it applies from the moment you create an account, and you do not have to request it. If your procurement process needs a countersigned copy of that same document, email support@supportshot.com and we will sign it.

Who else processes the data

We keep the list short on purpose. These are our subprocessors:

When that list changes

Adding or replacing a subprocessor that touches your tickets is a change you get told about before it happens, not after. We will email account owners at least 30 days before a new subprocessor starts processing, naming it and what it will do. If you object on reasonable data-protection grounds within those 30 days, tell us at support@supportshot.com: we will work with you to find a way around it, and if there is none you may terminate your subscription for the affected service and we will refund the unused part of what you have paid. Replacing a subprocessor with one doing the same job on the same terms follows the same notice. Nothing here applies to a change we make in an emergency to keep the service running or secure — there we will tell you as soon as we can afterwards, and the objection right and the refund still apply.

The list above is the whole list. We do not use analytics, advertising, session-replay, error-tracking, or AI vendors, so none appears on it.

We will also disclose data if the law requires it — a valid court order, for example — and we will tell you unless we are legally barred from doing so. If the business is ever sold or merged, your data moves with the service and you will be told before it does.

Where the data lives

Tickets, screenshots, and the database sit on dedicated servers we manage in Beauharnois, Quebec, Canada, rented from OVH Hosting Inc. (OVHcloud); screenshots are stored on the server’s own disk, not in a third-party object store. Email delivery (Resend) and billing (Stripe) involve transfers to the United States, made under those providers’ standard contractual clauses. Nothing else leaves the country: Cloudflare, Inc. answers DNS queries for our domain name but is not in the path of your requests, which reach our servers in Beauharnois, Quebec, Canada directly, so no connection metadata is processed abroad.

How long we keep it

• Tickets and screenshots — until you delete them, or until your account is closed. We do not expire them on a timer. Deleting a ticket removes its screenshots from storage and invalidates the image links in already-sent emails.
• Account data — for the life of the account.
• Closing your account — the owner of a workspace can delete it themselves, from Org settings in the dashboard, confirming by typing the workspace’s name. That is not a request we process later: it deletes the projects, every report and both copies of every screenshot filed under them, the recipient lists, the per-project rate-limit counters, the usage counters, the workspace, and the accounts of everyone in it who has no other workspace — along with the sign-in rate-limit rows keyed on those accounts’ email addresses. It runs in one transaction and finishes before the page comes back. If you cannot reach the account, email support@supportshot.com from the address you signed up with and we do the same thing by hand within 30 days.
• The cancellation that erasure leaves behind — if the workspace had a paid subscription, the same transaction writes down the Stripe subscription and customer identifiers so that the cancellation cannot be lost, and we place it with Stripe immediately after the rows are gone. Those two identifiers are the only thing about you that survives the transaction, they are kept only for as long as the cancellation is unsettled, and the record is deleted within 14 days of it settling. Until that happens, a Stripe customer identifier is a pointer Stripe can resolve back to a person, so it is named here rather than folded into “everything is gone”. The one case that outlives the 14 days is a cancellation Stripe refuses outright, which stops being retried and waits for a human here — an unfinished obligation to you rather than a record we keep. What that means for your money is in the terms.
• The exceptions to all of that — backups (below), and the invoices and tax records Stripe is legally required to keep.
• Server logs — we do not keep per-request access logs at all. The application event logs we do keep are not kept to a schedule but overwritten on a rolling basis, usually within days and never beyond 30. “Site and service logs” above says what is in them and how the rotation works.
• Rate-limit counters — including the IP-derived keys that make them work, deleted within hours of the window they count closing.
• Backups — the one place data can outlive a deletion, and it would be dishonest to describe erasure as instant without saying so. Deleting a ticket, a project or a workspace removes it from the live systems immediately and irreversibly, but a backup copy taken beforehand still holds what it held when it was taken. Our rule is that no backup is kept for more than 14 days, so a deleted row can survive in a backup for at most that long and then it is gone. Backups exist to restore the service after a fault: they are not searchable, are never opened to answer a support request or a data request, and are held under the same access controls as production. If we ever restore one, we re-run every erasure that happened after it was taken, so a restore cannot resurrect a workspace somebody asked us to destroy.
• Notification emails already delivered to your recipients are in their mailboxes and outside our control.

Security

All traffic runs over HTTPS. Passwords are hashed with Argon2 and are never recoverable, by us or anyone else. Screenshots are served through authenticated routes in the dashboard, and through unguessable signed links — in notification email, and in the ticket exports described below — that stop working when the ticket is deleted and, in any case, 180 days after they were signed. Every submission is checked against your project’s allowed origins and rate limited. No system is perfect; if we ever suffer a breach affecting your data we will tell you promptly and tell you what we know — without undue delay and, where we are your processor, in time for you to meet your own 72-hour notification deadline.

One thing we do not do, stated plainly rather than left to be inferred from a list of the things we do: data at rest is not encrypted. The database, the screenshot files, and the backups sit unencrypted on the disks of servers we control. Passwords are the exception — they are hashed, which is not encryption and is not reversible. What protects the rest is physical and access control, not cryptography. If your risk assessment requires encryption at rest, this product does not meet it today, and we would rather you learn that here than after an audit. The full picture is on the security page.

Your rights and choices

• See it — every ticket is visible in your dashboard, and you can download them without asking us: Projects → the project → Settings → Export tickets gives you every report that project has ever received as a file, in either JSON or CSV. Two things to know about its scope. It is one project at a time, not one button for the whole workspace — a workspace with four projects is four downloads. And it is an export of reports: your workspace and account records, a project’s settings and its notification recipient list are not in the file. For those, or for anything else you want a copy of, email support@supportshot.com and we will put it together for you. Keep the JSON, and the difference between the two formats is not cosmetic: a report carries the page context, the console log and the network log, and those are nested structures rather than columns. The CSV exists because the person who asks for an export is usually not the person who reads JSON, and it flattens each of those three into JSON text inside a single spreadsheet cell — nothing is missing from it, but it is no longer a table you can sort by. Screenshots are files rather than database rows, so neither format contains the image; both link to it, with a signed link that works without signing in. Two things end that link: deleting the ticket, and time. It is signed for 180 days from the moment the file is downloaded, and after that it answers with a note saying where the image still is rather than showing it — re-export the project for fresh links, or open the report in the dashboard, which has no expiry to run out. Treat an exported file as being as sensitive as the reports in it, and as one that stops being a key to them after six months.
• Correct it — your workspace name, your projects and their settings are editable in the dashboard, and so is the address you sign in with: Account in the dashboard changes it. We ask for your current password, then send a confirmation link to the new address — the change happens when you follow that link, not when you submit the form — and we tell the old address that it was asked for, so a change nobody at your end requested does not go unnoticed. If you sign in with Google and have never set a password, that route is closed to you (there is no password for us to check, and changing the address would split the account at your next Google sign-in); email support@supportshot.com instead. The name on your account is still written at signup and has no editor anywhere in the dashboard: email support@supportshot.com and we will correct it for you.
• Delete it — delete individual tickets from the dashboard; delete a whole project, with its reports and screenshots, from that project’s settings page; or, if you are the workspace owner, delete the entire workspace and every account in it from Org settings. Each of those happens immediately and cannot be undone. If you cannot reach the account, email support@supportshot.com and we will do it for you.
• Object or restrict — email support@supportshot.com and tell us what you want stopped.
• Complain — if you are in the EEA or UK you may complain to your local data protection authority. We would rather hear from you first.

We answer requests within 30 days and do not charge for them.

If you filed a report on someone else’s website

The website that showed you the SupportShot widget decides what happens to your report; ask them first, since they hold the account. You can also email support@supportshot.com with the ticket reference from the confirmation message (for example SS-4F2A9C) or the email address and website you used, and we will locate the report and pass your request to the account owner, or act on it directly where the law requires us to.

If our emails arrive and you never signed up

Notification emails come to the addresses a SupportShot customer listed as recipients for their project. If you are on one of those lists, it is because the person who runs that website added your address, and every message you receive is a bug report one of their visitors filed. We send it; they chose the list.

These are service messages rather than marketing, and there is no newsletter to leave — but you should not have to keep receiving them either. Every notification we send you has an unsubscribe link at the bottom. Following it shows you which address and which project it will remove and asks you to confirm — one button, no account, no password, no reason asked — and the removal happens the moment you press it. We ask for that confirmation because scanners and previewers open links in email before you do, and we would rather not take you off a list your own security software clicked. If your mail app shows its own Unsubscribe button beside the sender, that works too and skips the page.

Two routes that do not depend on that link. You can ask whoever runs the website, who can remove your address in their project settings in a few seconds. Or email support@supportshot.com from the address receiving the mail, quote one of the messages, and we will remove you ourselves and tell the account owner we have. We do not need a reason and we will not ask for one. Either of these is the answer if a link has expired — they are signed for 90 days, so one in a message older than that will tell you to write to us instead.

What an account owner receives

If you hold a SupportShot account rather than only receiving its notifications, there are two other kinds of message. One is the over-limit notice — at most once a day, while your workspace is over its monthly ticket allowance. That one is commercial, and writing to support@supportshot.com stops it.

The other is a notice about your account or the agreement it is under: a personal data breach affecting your data, a new subprocessor, a price change, a change to these documents, or the service being discontinued. Each one names the clause that obliges us to send it and is sent no later than the notice period that clause gives — 30 days for a subprocessor or a price change, 14 for a change to the terms, 60 for discontinuation. These are rare, written by a person, and they go to the email address on your account. They have no unsubscribe and cannot be stopped, because there is no version of being told that your data was breached that you can usefully opt out of while you still hold the account it is about. Closing the workspace is what ends them. They are not marketing, we do not use this route for anything else, and there is no announcements list or product newsletter to be on.

Cookies

supportshot.com sets a small number of strictly necessary cookies, for keeping you logged in and for CSRF protection. There are no advertising cookies, no third-party analytics, and no tracking pixels on this site. The widget on your site sets no cookies at all.

The report widget on this site

We do not currently run the SupportShot widget on supportshot.com. No report button is served on these pages, and no console, network or page data is collected from your visit here by it. If we switch it on, this section changes with it in the same deploy — the sentence you are reading and the widget are controlled by the same setting, so one cannot be true while the other is not.

Children

SupportShot is a tool for website operators and is not directed at children under 16. We do not knowingly hold account data about children. If a child’s personal data reaches us inside a bug report, tell us and we will delete it.

Changes to this policy

When we change this policy we update the date at the top. If a change materially affects how we handle your data we will email account owners at least 14 days before it takes effect. The terms of service cover the rest of the relationship.

Contact

Privacy questions and data requests: support@supportshot.com. The data processing agreement needs no request — it is published at /dpa and already applies.

In writing: 2662415 Ontario Inc., 408 Dundas Street South, Unit 101, Cambridge, Ontario N1R 8H7, Canada. There is no separate data protection officer; requests reach the people who run the service, and a person answers them.