Privacy Policy

You give oloy a URL. oloy opens it in a real browser, works out what the app is for, and then runs its important flows on a schedule — navigating, filling forms, submitting them, and verifying that the thing the flow promised actually happened. When something breaks, oloy tells you what broke and drafts a prompt you can hand to your coding tool.

That is a more invasive thing than an uptime check. To do it, oloy records what your application displays: the page’s text, its underlying HTML, screenshots, and video of the browser session. If your app is showing real customer data when a check runs, that data is in what we record. The rest of this page is what happens to it.

oloy is built and run by Matan Green, as an individual rather than through a company — “we” and “us” on this page mean him, and he is the person responsible for the data described here. For anything on this page, including a request about your own data, write to hi@oloy.ai.

Signing in. oloy signs you in with Google, and only with Google. We ask Google for basic profile and email address — nothing else. oloy has no access to your Gmail, Drive, Calendar or any other Google service.

From that sign-in we store:

• your name, as Google gives it to us;
• your email address;
• the address of your Google profile picture;
• Google’s own identifier for your account, and the tokens it issues so the connection keeps working;
• a session record — a random token and an expiry — matching the cookie in your browser.

There is no password for oloy, so we hold none. We also store your workspace: its name, who is in it, invitations you send (which contain the invited person’s email address), and whether notifications are switched on.

If you email us, we have that correspondence. We do not collect payment details: oloy takes no money today and has no payment integration.

For each application you add: its URL, the name you give it, which environment it is (production, staging, and so on), optionally the stack it is built with, how often you want it checked, any free-text note you leave describing it, and any alert destinations you configure — an email address, a Slack destination or a webhook address.

Every time oloy looks at a page, it keeps:

• a screenshot of the page;
• the page’s full HTML;
• the accessibility tree — the structured description of the page the browser exposes to screen readers — and a plain-text rendering of it;
• the URL;
• browser console messages, uncaught errors, and failed or slow network requests;
• for flows it replays, a video recording of the browser session.

We have no way to redact your application’s content before recording it, and we do not claim to. A recording of your app running is a recording of whatever it was displaying. Point oloy at an environment whose contents you are comfortable having recorded.

While it runs a flow, oloy also types into your app: it fills form fields with made-up values and submits them, which creates data inside your application. It holds back and asks you first only where it judges an action to be destructive.

Most flows worth checking sit behind a login, so oloy needs a way in. What we do with what you give us:

We do not store your application’s password in oloy’s database. There is no column for one. What is stored against an app is the method (a password login or a magic link) and the identifier — the username or email address oloy signs in as.

Where a secret is genuinely needed to run a check, it lives in configuration on the machine that runs the checks, is passed to the browser process that signs in, and is used only against the application you supplied it for. Signing in produces a browser session — cookies your app issues — which may be kept on that same machine so a later check can resume without signing in again.

We do not add encryption of our own on top of what our hosting and operating system provide. Do not treat oloy as a secrets manager, and prefer a dedicated test account over your own.

This is the disclosure that matters most on this page. To work out what a page is for, what a flow should do, and whether what happened counts as a failure, oloy sends what it captured from your application to a third-party AI provider.

What is sent: the page as text — the accessibility tree rendered out, which is the visible text of the page plus the labels of its controls — along with the URLs visited, the console messages and network failures recorded, and a description of the flow being checked. It is sent as captured. It is not redacted first.

What is not sent: screenshots and video. Today the models receive text only; images stay with the recording.

Who receives it: Google, through its Gemini API. Every part of oloy that consults a model is currently pointed at Google. oloy can also route to Anthropic’s Claude API — that path is built and shipped — but nothing is pointed at it today. What either provider does with what it receives is governed by that provider’s own terms. If the provider changes, this page changes with it.

We do not train models on your application’s content. We do not build models at all.

oloy is in early access, and it is deliberately not autonomous yet. When oloy concludes something in your app is broken, the message it composes for you is held, and a copy goes to the person operating oloy, who reads it before anything reaches you. That copy carries the same facts yours would: which app, which flow, what broke.

Two consequences, stated plainly: a person at oloy sees what oloy finds in your application, and an alert may reach you later than the check that produced it. This is a property of early access, not of the design; when it changes, this page changes.

• Accounts, workspaces, apps and results — a PostgreSQL database operated by Render in Frankfurt, Germany. The website and API run on Render in the same region. Access to that database from the open internet is closed; only addresses the operator explicitly allows can reach it.
• Screenshots, video, HTML and everything else a check records — on the machine that ran the check. Today, checks are run from a machine the operator controls rather than from the hosted service; only the results — the rows describing what passed and what broke — are published to the database above. Object storage for those files is built but not yet in use.
• The text sent for analysis — goes to the AI provider named in section 7, on that provider’s infrastructure.
• How oloy’s own interface is used — with PostHog, a company in the United States, on its US infrastructure. What that covers, and the much larger thing it deliberately does not, is section 10.
• DNS for our domains is managed by Cloudflare.
• Anything you write to hi@oloy.ai — Cloudflare takes the mail for the domain and forwards it to a personal Gmail account, which is where it is read and where it stays. There is no help desk in between, and a reply reaches you from that Gmail address rather than from hi@oloy.ai. A deletion request, like every other message, passes through both companies on its way to being read.

We use PostHog to understand how oloy itself is being used — which screens people open, what they click, and whether something they started ever finished. It gives us three things: product analytics, a replay of the session, and feature flags, which are the switches that let us turn a piece of behaviour on or off for one account without shipping new code.

What it records: the pages you open inside oloy, and the handful of moments this product deliberately reports — an app connected, a check requested, a flow opened, a question answered. It also records a replay of the oloy interface: a reconstruction of the screens you moved through, so we can see where the product confused you. Events are tied to your account by the identifier our own database gives you, and by nothing else — we do not send your name or your email address to PostHog.

What it deliberately does not record, which on this product is the part that matters: every screenshot, video and page capture from your application is blocked, and every piece of text on the screen is masked, in your browser, before anything is sent. That is the default for every screen in oloy rather than a decision made page by page — nothing has to be marked, and a screen built next month is covered because of what it is made of. So the replay we can watch shows you using oloy; it does not show us your app.

Where it goes and how long it stays: PostHog is a United States company and the data sits on its US infrastructure. On the plan we are on, session recordings are kept about thirty days and then age out; what PostHog does with what it receives is governed by its own terms.

How to make it stop. Write to hi@oloy.ai and we will switch the recording off for your account. It is a flag we hold rather than a setting you have to find, so it takes effect the moment we flip it, with nothing to deploy.

Where it runs, including the part people are surprised by. Analytics runs on the signed-in product and on the sign-in page. The three pages you can read without an account — this one, the Terms of Use and the front page — carry none of it: PostHog never starts there, so it makes no request and sets no cookie. The sign-in page is the exception, and it is a deliberate one: signing in is the one step of this product we cannot otherwise tell succeeded or failed for you, because it happens at Google and then against a list of who is allowed in, and a refusal at either leaves no trace anywhere else. So if you open the sign-in page and leave without an account, that visit was measured and the cookie in section 12 was set on your browser.

What that page can see, precisely. That it was opened, that it was opened from this browser, and — if you go on — that signing in worked. Alongside that goes what any request to a server carries anyway: your browser and operating system, the kind of device, your time zone, and your IP address, which PostHog turns into an approximate location at its end. Not your email address and not your name: what we send is the identifier your account already has in our database, and only once you have one. The recording of that page is masked like every other, so it shows the shape of the page and no readable text. And nothing about your app’s own content is in any of it to begin with — on that page there is not yet an app.

• No advertising and no tracking services run on this site: there is no advertising pixel, and nothing here follows you onto anyone else’s. The one analytics tool we do use is PostHog, on the signed-in product and on the sign-in page, and section 10 says exactly what each of those sees. The front page, the Terms of Use and this document carry none of it.
• We do not sell your data, and we do not share it for anyone’s marketing.
• We do not train models on it.
• We do not collect payment details.

Only what signing in needs, and one for the analytics in section 10. A session cookie is set when you sign in, so you stay signed in; it lasts up to thirty days. Two more are set by our authentication layer on any page you open, this one included — a cross-site-request token and a note of where to return you after a sign-in. A demo cookie exists for local development and is inert in the deployed product.

PostHog sets one cookie of its own, named ph_<project>_posthog, which holds the identifier that ties your visits together and a note of the current session. It is set on the signed-in product and on the sign-in page — so opening the sign-in page sets it, whether or not you go on to sign in. It is not set on this page, not on the Terms of Use and not on the front page: PostHog never starts on any of those three, so there is no request to make it with and no cookie to set. Section 10 says why the sign-in page is in.

There are no advertising cookies, because there is no advertising.

What a check records from your application — screenshots, video, the page HTML, the accessibility capture and the console and network logs — is kept for 90 days from the run that produced it, and then deleted. Ninety days is long enough to look back at what broke and short enough that a recording of your application is not still sitting on a disk a year later.

Today that deletion is a person, not a scheduled job. Nothing in oloy removes a recording on a timer, so the ninety days are kept by hand — we would rather write down a period we mean to keep, and tell you how it is enforced, than quote you a schedule nothing runs. When it becomes automatic, this page says so.

What the ninety days does not cover, said here rather than left for you to find: oloy is built by pointing it at test applications of our own and at public websites picked to try it against, and those runs are development material rather than anyone’s account data. They sit outside this clock, and some of them are already older than ninety days. Nothing recorded from an application you added is among them.

Your account, your workspace, your apps and the results — the rows saying which flow passed and which broke — stay for as long as your account is open. Ask us to delete an app, or the account entirely, and we will; if oloy shuts down, all of it goes with it.

One deliberate exception: the record that we told you something is kept even when the run it described is removed, so that “did oloy ever report this?” always has an answer.

• Everything is served over HTTPS.
• Sign-in is by invitation. An address that is not on our list cannot create an account, and a session belonging to an address later removed from it stops working rather than running out its cookie.
• The database is not reachable from the open internet by default.
• Ask us to delete something and it is deleted — by hand, by the person who runs oloy, and confirmed to you when it is done.

Those are the controls. What is not here matters too: oloy is a very small operation, it has no security certification and has not been through a formal compliance program, and nothing on this page should be read as a claim of conformance with any particular regime.

Concretely — if your application handles health records under HIPAA, or card payments under PCI-DSS, or your procurement process will not clear a supplier without a SOC 2 report, oloy is not yet the right tool for you. Those are the situations we mean; we are not waving off everyone with something worth protecting.

Write to hi@oloy.ai and you can ask us to show you what we hold about you, correct it, delete a single application and everything recorded for it, or delete your account entirely. We do this by hand and confirm when it is done, within thirty days of your asking — that limit covers every deletion you ask us for, here or in the Terms of Use.

You can also stop the recording at any time by asking us to remove an app — no further checks run against it once it is gone.

When what oloy does with data changes, this page changes with it and the date at the top moves. The parts most likely to change first are named in this document: the AI provider in section 7, and the human review in section 8.

Write to hi@oloy.ai. It is the only address, and it reaches the person who runs oloy.