Privacy policy

In effect 14 August 2026

We hold two very different things: a little about you, because you have an account, and a lot about your software, because that is the product. We hold essentially nothing about the people who use your app — not because we discard it, but because it never reaches us.

Who is responsible

Sixty is run by Sergio Sola Dominguez, an individual rather than a company, of Vilanova i la Geltrú, Barcelona, Spain. He is the data controller for your account, and acts as a processor on your behalf for the telemetry your applications send us. Every “we” below is one person — reach him about anything on this page at [email protected].

Your account

When you are given an account we store your email address, a display name derived from it, a hash of your password, the organisation you belong to, and your role in it. We store the API keys issued to that organisation as hashes, so a key cannot be recovered from our database after it is shown to you once — public browser keys are the exception and are stored in full, because a key embedded in a page is not a secret.

We also keep an operational record of which coding agents have connected with your keys, how many calls each has made, and when it was last seen. That is how the settings page can tell you an integration has gone quiet.

What your applications send us

Once installed, our libraries report measurements about your software. In full, that is:

• Names of operations — route patterns, function names, query shapes — and the file and line they come from, with stack frames.
• Normalised SQL. Literal values are replaced inside your own process, so where email = '[email protected]' reaches us as where email = ?.
• Counts and distributions: calls, durations, rows returned, bytes, database calls per render, error counts.
• Page performance from real browsers — largest paint, interaction response, layout shift — aggregated per route.
• Release identifiers, picked up from your deployment platform, so a change can be attributed to a deploy.
• Browser error groups, keyed by the code location that raised them rather than by the message.

What we do not receive

This is the part worth being exact about, because it is a design decision rather than a policy we could quietly relax.

• No IP addresses of your users. Not stored, not logged, not looked up. Where you see a country breakdown, that country arrived as a two-letter code on a request header, already resolved by your own CDN before your code ran. The address stays inside your infrastructure. We cannot geolocate anyone because we are never given anything to geolocate.
• No user identifiers or session identifiers. There is no field for one.
• No URLs. Addresses are reduced to their shape — /orders/:id — in the browser, before anything is sent, so identifiers in paths and query strings never leave the page.
• No cookies set on your users, no click recording, no session replay, and no text from your pages.
• No values from your database. Only the shape of the query that asked for them.

The consequence is real and we would rather state it than hide it: we cannot tell you who hit a problem. We can tell you what broke, on which route, after which deploy, and how often.

Why we are allowed to hold it

For your account and for keeping the service running and secure, our basis is the contract between us, and our legitimate interest in operating and defending the service. For telemetry, we act on your instructions as your processor — you decide what your software reports and you can stop it at any time by removing the integration. We do not sell anything to anyone, run advertising, or use your data to train models.

Who else touches it

A short list of companies process data on our behalf, and one of them is worth naming here rather than only on a page you have to click through to: detected findings are sent to DeepSeek to be explained in plain English. That payload is the finding — metric names, normalised SQL, file names, frames, before and after numbers. There is no end-user data in it because none was collected. The complete list is on the sub-processors page.

How long we keep it

Deliberately short, and enforced by a job rather than by intention:

• Trace exemplars — the detailed evidence behind a finding — 3 days.
• Per-country page timings, 7 days.
• All other performance rollups, 30 days.
• Findings themselves are kept until you delete them or close your account, because a finding you dismissed is a decision, and losing it would mean showing it to you again.
• Account records are kept while the account exists.

Where it is processed

Hosting and processing locations are listed on the sub-processors page. Where a provider is outside the European Economic Area, transfers rely on the European Commission's standard contractual clauses.

Cookies

This site sets four of its own: your session, your theme, which services you were last looking at, and your answer to the question below. All first-party, all necessary for something you asked for.

It also offers you Google Analytics, which we use to count how many people who read our marketing end up with the product working. That is two more cookies, they are Google's, and they are only set if you agree — say no and the tag is never loaded at all. There is a page about all of it, with a cartoon on it: cookies.

This is about visitors to this website. It is not about the people using an application you have instrumented — we receive nothing that identifies them, which is described at the top of this page and is unaffected by any of the above.

What you can ask us to do

If you are in the UK or the EEA you have the right to a copy of your data, to have it corrected, to have it deleted, to restrict or object to how we use it, and to have it sent somewhere else in a portable form. Ask at [email protected] and we will answer within one month. You can also complain to your national data protection authority; we would rather you told us first, but it is your right either way.

If your request concerns telemetry from an application belonging to a customer of ours, we will pass it to that customer, because it is their data and we hold it on their instructions.

Security

Passwords are hashed. API keys are stored as hashes and shown once. Traffic is encrypted in transit. Ingest keys and agent keys are separate scopes, so a key sitting in a container's environment to report latency cannot read your findings. Found a hole? Please tell us at [email protected]; we will not take legal action against anyone reporting a vulnerability in good faith.

Children

This is a developer tool sold to organisations. It is not directed at children and we do not knowingly hold data about them.

Changes

If we change this in a way that matters, we will say so on this page and email account holders before it takes effect. The date at the top is the version you are reading.