last updated 2026-10-14 · aerology.ai and app.aerology.ai
As of the date above there is no account here, we do not ask who you are, and the only thing you tell us is which flights you are asking about. What follows is what actually happens to that — read off the code and the infrastructure on that date, not off a template.
A forecast needs the flights in your trip, and — only if you move it — the minimum connection time you want us to assume. That is the entire input. Nothing else about you is collected or required.
Today there is no account and no password. No form on either site asks for your
name or your email address. The addresses on the landing page are ordinary
mailto: links: if you write to us, we have your mail, the same as any
other correspondence.
One of them is the waitlist. Joining it means writing to waitlist@aerology.ai from your own mail; nothing is sent to you automatically. We keep your address and your message to write to you when programmatic access opens, and for nothing else. To be taken off the list, write to the same address or to privacy@aerology.ai, and we delete your mail.
When the app answers a forecast, it writes one line to its own log:
That line carries no name, no account, no cookie value and nothing derived from your IP address. The fingerprint is a property of the itinerary, not of you: two strangers looking up the same trip produce the same one.
Those lines are copied into a data warehouse we own, where each day's rows are deleted 365 days after they arrive. We keep them to answer two questions: how much the service is being used, and whether anyone moves the connection minimum.
The app writes a few other kinds of line to the same log, and they are copied to the warehouse too: for the results page's history chart, the same fingerprint and leg count as a forecast; when you look up flights, the two airports you asked about; when it loads the national figures on the front page, whether it could read them and how old they were; and when it turns away a request that did not come from one of its own pages, which address was asked for and which request headers were missing or pointed elsewhere. None of them carries a name, an account, a cookie value or anything derived from your IP address.
From a device set to a US time zone, the app's pages also send a short report of their own. It says how long the page took to draw and to respond; whether it hit an error, by the kind of error and where the page caught it, never the error's message; which of the page's layouts was showing and whether the screen is touch or mouse; and which of a few steps the visit reached: the front page, opening a leg, adding a connection, asking for the odds, the results drawing, their history drawing, and moving the delay slider. It carries no flight, no address and nothing about your browser beyond those. Each report carries a random number made when the page loads, so the steps of one visit can be read together. It is never stored in your browser and is gone when you close or reload the page. The reports are copied to the warehouse and deleted after 365 days, like the lines above. They arrive like any other request, so the web-server log below notes each one's IP address for its 30 days; we never use that to tie a report to anyone. From a device set to any other time zone, the pages send nothing.
Two things that are true and easy to leave out. When a flight cannot be resolved at all, the app logs that flight's reference so we can report it upstream. And Google Cloud keeps its own web-server log for the app, the way any web server does: your IP address, your browser's user-agent string, the page that linked you here, and the URL you asked for — which, for a forecast, contains the flight references. We do not copy that log into the warehouse; it stays in Google Cloud Logging, where this project's default bucket keeps 30 days. We query it where it stays, to count visits by page, by the site that linked to us and by kind of device, and to tell people from automated clients. Those counts use nothing derived from your IP address and keep nothing about any request.
This landing site has a web-server log too. Firebase Hosting writes it to the same
bucket, where it is kept for 30 days: your IP address, your browser's user-agent
string, the page that linked you here, the URL you asked for, and the country and
city Google works out from your IP address. It is not copied into the warehouse
either, and we count from it the same way, using nothing derived from your IP
address. /llms.txt, a machine-readable descriptor for automated
clients, is served by a small service of ours and is logged like the app.
The app sets no cookies of its own, and it keeps nothing about you in your browser — no cookie, no local storage. Neither does this site.
aerology.ai as a whole is not cookie-free, though, and we would
rather say so than write a sentence we would have to defend. Our newsletter,
logbook.aerology.ai, is hosted by Substack and sets
_gcl_au on .aerology.ai itself — a Google Ads cookie,
about 90 days — so your browser sends it to every subdomain, this one and the app
included. Substack controls the tags on that page; we do not.
If you ever visited at-booking.aerology.ai, a page left over from the
site before this one and since retired, your browser may still hold the Google
Analytics cookies it set on .aerology.ai, and send them here until
they expire.
Nothing we run reads any of them.
storage.googleapis.com.
The forecasts themselves are ours. They are computed by our own model service, in our own Google Cloud projects, from the flights you gave us. Your trip is not sent to a third party to be answered.
Three things on this page describe the beta (the research preview) as it stands rather than what comes next:
If any of this changes, this page changes first, and the date at the top says when.
Write to privacy@aerology.ai. If anything on this page turns out not to match what the software does, that is a bug — tell us, and we will fix the page or the code, whichever is at fault.