Questions about a product
that has not launched yet.

DwellTime.aero is a signal layer for businesses around airports. It reads airport disruption, including weather, delays, cancellations, congestion, and irregular operations, and turns it into short-range business signals: how long passengers are likely to stay, and what that is likely to mean for your kind of business.

It is not an aviation data feed and not a footfall counter. The output is a level, a time window, a confidence value, reason classes, and suggested actions. The product page explains how the scores are built.

Passenger dwell-time pressure is the risk that passengers stay in a terminal longer than usual. Demand pressure is the expected change in demand for a specific business type. Airport disruption risk is the risk that operations and passenger flows are affected.

Each score uses four levels: LOW, MEDIUM, HIGH, and CRITICAL. Each one carries a risk window covering the next 1, 3, or 6 hours.

No. Dwell-time pressure is a risk score, not a measurement. It estimates whether passengers are likely to stay longer than usual at this airport at this hour. It does not time individual passengers and does not report actual footfall in your unit.

If you need measured counts inside your own premises, that is a different category of product. DwellTime is designed to sit alongside it rather than replace it.

No, and we will not pretend otherwise. A wave of cancellations can reduce arrivals while raising demand from passengers already in the terminal. A morning of delays can push a lunch peak two hours later rather than making it bigger.

That is why demand pressure is scored per business type and always carries reason classes. The reasons tell you which way to read the level.

Footfall and passenger flow analytics measure what is happening now, usually with sensors or counters inside a building. DwellTime looks outward and forward instead. It reads the state of the airport and estimates pressure in the hours ahead.

The two answer different questions. One tells you how busy you were. DwellTime is designed to tell you what may be coming.

In plain terms, from operational information about airports and flights: scheduled and actual movements, delay and cancellation patterns, aviation weather conditions, and indicators of congestion or irregular operations. Those inputs are combined into the three scores rather than passed through to you.

We are not a weather data reseller. Naming the source categories is background, not the product. The developer overview describes the output you would actually receive.

The confidence score is a value between 0 and 1 that describes how much support a signal has behind it. A lower value usually means thinner or less consistent input, or a situation that could still resolve in more than one direction.

Treat it as a guide to how firmly to act. A HIGH level with low confidence is a reason to watch the next update, not a reason to commit an extra shift.

Reason classes are short machine-readable tags that explain why a score moved, for example rising delay pressure or a weather disruption risk. They are meant to stay stable enough that a platform can build routing rules against them.

They exist so that a signal is never a level without an explanation attached.

No. There are no cameras, no sensors installed on your premises, and no per-passenger tracking. DwellTime does not identify travellers, follow devices, or process personal data about the public.

How business contact and account information is handled is set out in the privacy notice.

It will sometimes be wrong. Any short-range risk score is. A HIGH level that does not turn into a busy hour is a normal outcome rather than a defect, which is why every signal carries a confidence value and a window instead of a promise.

We will not publish accuracy figures we cannot support. Measuring how often the scores are useful, on real sites, is part of what the pilot is for.

The person who can act inside the window. That is usually a duty manager, a shift lead, or a dispatcher, not a head office analyst. A signal about the next three hours is only useful to someone who can change the next three hours.

Alerts are planned for email, Slack, and webhooks alongside the dashboard. See integrations for the planned delivery channels.

The planned windows are the next 1, 3, and 6 hours. That range is deliberate. It is long enough to call someone in, move stock, or hold drivers back, and short enough that the airport picture is still meaningful.

DwellTime is not a seasonal planning tool. For next month's roster you want your own historical data.

No. They are prompts, scoped to a business type, such as reviewing staffing or preparing more grab-and-go stock. You know your site, your team, and your margins. We do not.

DwellTime will also never act for you. It does not change rosters, place orders, or dispatch vehicles on your behalf.

That is the intent. A REST API and a WebSocket event stream are planned for the MVP, so signals can be pulled into a tool you already use, and webhooks can push events into your own rules.

Which integrations ship first will depend on what pilot participants actually need. The developer overview shows the planned payload shape.

The same scores, delivered differently. A single cafe, hotel, or transfer company is expected to work from the dashboard and alerts, with a short watchlist covering the airports and terminals that matter to them. No engineering work required.

A platform or operations team is more likely to consume the API and the event stream and build the signals into its own product. The platforms page covers that path.

No. DwellTime is in active development and nothing is live. This site shows the planned experience using illustrative data. Every airport code, score, and sample payload you see is an example, not an observation.

What you can do today is talk to us about the pilot.

Coverage has not been announced, and there is no launch date. We are not going to list airports we cannot yet support, or commit to a date we cannot yet stand behind.

First coverage will follow from where pilot participants actually operate and where the input signals are strong enough to be worth acting on. We will announce it when it is real.

Pricing is not defined. There are no plans, no tiers, and no published rates, and anyone quoting you a DwellTime price today is guessing.

Pricing will be shaped with the first participants, once we know what the product actually delivers for a working site.

At this stage it is a conversation, not a contract. We want to understand your operation: which airport and terminal you work around, what your day looks like when things go wrong, and which decision you would want a few hours of warning on.

There is no fee, no commitment, and nothing to install yet. If it turns out DwellTime would not help you, we would rather establish that early. Start on the pilot page.

Whatever you tell us in a pilot conversation is used to shape the product and to judge whether a pilot is a fit. We do not publish it, and we do not use a business name as a reference, logo, or case study without written permission.

The privacy notice sets out how contact details and business information are handled.