TLDR: 7 checks across the Notifications screen — reading the two tabs, filtering the Comms inbox, scanning the flight alert list grouped by flight, opening a card to see when the flight departs, and confirming that tapping a push notification takes you to the alert it was about rather than dumping you at the top of a list. Checks 1–3 need no login. The flight alerts you see may be a sample flight — the screen says so when they are.
Steps: From Page Readiness, tap Notifications — Comms + Flight Finder. Then tap FLIGHT FINDER, then COMMS again.
What you should see: Two pills at the top. COMMS is selected when you arrive and shows a list of ALPA and MEC messages. FLIGHT FINDER shows flight alert cards. The filter icon in the top-right belongs to Comms only and disappears on the Flight Finder tab. Switching away from a tab counts as having read it: any red unread dots on the list you just left are gone when you come back to it. Leaving the Notifications screen entirely does the same for both tabs — the same rule the native app applies.
Steps: On the COMMS tab, tap the filter icon (top right). Tick an audience, tap Apply. Then reopen it and tap clear.
What you should see: The list narrows to that audience and a small count badge appears on the filter icon. Clearing restores the full list and removes the badge.
Steps: Switch to FLIGHT FINDER and read down the list without opening anything. If you have alerts for more than one flight, this is the check that matters most — subscribe to a second flight in Flight Finder first if you only have one.
What you should see: Alerts grouped by flight, not one long stream. Each group starts with a pale blue header bar carrying the route (ORD » DEN), the flight number beside it, and a count on the right — 3 updates. Tapping the header collapses that flight's alerts and tapping it again brings them back; groups start open. Beneath each header are that flight's white cards, newest first, each with the time the alert arrived in the top-right corner. Each card leads with a pill saying what changed — GATE CHANGE, ARRIVAL UPDATED, TIMES UPDATED, DELAYED, CANCELLED — with how long ago the alert arrived on the same line, and beneath it the alert's own sentence: "AA4216 from ORD to DEN now departs from gate L10B." The sentence is the only place the specifics appear — the pill says GATE CHANGE, the sentence says which gate.
When one alert reports several changes at once — a gate move, new times and a delay in the same sentence — the pill names the most consequential one, not the first one mentioned. The order is: cancelled, then delayed, then gate, then times. So an alert reading "now departs from gate T12, departs at 21:29, arrives at 23:36, has a status of Delayed" shows a DELAYED pill with the amber triangle, even though a gate is named first in the sentence. That is correct, not a mislabel — the sentence beneath still lists every change. Before 2026-08-19 that same alert showed GATE CHANGE and the delay was invisible on the card.
A red dot beside the elapsed time marks alerts you have not seen yet; it clears when you open the alert, switch tabs, or leave the screen. Neither the route nor the flight number is repeated on the card, because the group header directly above already carries both.
Every pill looks the same — same blue, whatever the change. That is deliberate: the icon on the left is what carries urgency. A gate change shows a figure hurrying, a time change a clock, a departure a plane with a bar behind it and an arrival the same plane with the bar ahead of it, an out-gate a jumpseat. Delays are an amber warning triangle and cancellations a red one — those two are the only coloured icons on the screen, so anything coloured is worth reading first. An alert we cannot classify gets a grey warning light rather than a guessed icon.
Every icon, in one place. You will not see most of these on a normal pass — a flight has to actually be delayed or cancelled for those two to appear, and DEPARTURE UPDATED needs an alert that changes the departure without touching the arrival, which we have never seen the live service send. Use this to check the glyph matches the pill on whatever you do get, rather than expecting to collect the set.
One flight's alerts under its header. Each card is a pill, how long ago, and the alert's own sentence — which is the only place the actual gate appears.
Where one group ends and the next begins. Different flights on the same city pair stay separate, and the pill differs per alert — ARRIVAL UPDATED above GATE CHANGE.
Both shots are live data, not the sample flight. The yellow sample note appears only when you have no subscriptions of your own.
Worth reporting, not a bug: the date under the card is the flight's departure, and it comes from the flight you saved when you subscribed. If you have deleted that saved flight, the card falls back to showing when the alert arrived and says NOTIFICATION RECEIVED above it — that is expected. What is worth telling us is whether the departure date is the more useful thing to see there. Also expect the route to appear twice for now, once on the header and once on the card; that duplication is known and under review.
Steps: Tap the small caret at the bottom of a card. Then tap the caret on a different one.
What you should see: A line appears with the date and time — either the flight's own departure, or, when the flight is no longer in Saved Flights, the time the alert arrived labelled NOTIFICATION RECEIVED. That is all the caret reveals: what changed and the alert's own wording are on the card already, so this is context rather than substance. The caret flips while the line is showing. Opening a second card leaves the first open — this is no longer an accordion, and you can have as many showing as you like.
Entering from the readiness row (?showcase=true) adds more below that line: a
Sent row (the server's send time from the payload — the app never records when the device
received it) and VIEW FULL DETAILS ›. That is the alternate detail view, kept
deliberately so the design team can compare the retired richer card against the drawn one (see the
notes). Production entries — a push tap, the bell — show only the date line.
That link is not part of this walkthrough. It opens a per-flight update history screen that predates the grouped list: it lists every alert for one flight on a page of its own. The list now does that job — a flight's group header and its cards are the same set of updates, in the same order — so the screen survives as a design-comparison surface rather than something a member is meant to reach. Nothing to test there; if you land on it, back out and carry on.
Captured on an engineering build — the raw Flight reference row in the showcase view is debug-only and does not appear on the ad-hoc/UAT builds testers run.
Steps: The truest version is the real thing: from Page Readiness open Push / Deep-link Test Scenarios and tap Real push tap → post a local notification. About five seconds later an actual OS notification arrives carrying a real alert's payload — the banner shows even with the app open. Tap the banner.
What you should see: The Flight Finder tab opens with that alert scrolled into the middle of the screen and its date line already open, under its own flight's group header. Arriving from a push is the one case where you did not pick the card off a list, so it should be the only card opened for you.
Steps: On an Android device, from Notifications: open the Comms filter sheet, then use the system back gesture (swipe in from the screen edge). Next open a flight's update history (Check 4's history link) and back-gesture again. Finally, on the Notifications list itself, back-gesture once more.
What you should see: First back closes the filter sheet and leaves you on the list. Second back pops the history screen back to the list. Third back, from a top-level screen, returns to the app's start destination (Home) rather than exiting the app.
Steps: Find a Comms notification whose action is a phone number (a "Call …" action). Tap it.
What you should see: The phone's own call confirmation appears (iOS: the "Call number?" sheet; Android: the dialer opens with the number filled in, waiting for you to press call). Cancelling leaves you on the notification. The same applies to phone numbers in the drawer.
These run with the unit suite, so a regression should be caught before it reaches you. Run the checks by hand anyway — the automation checks the behaviour is present, not that it reads well:
Classify_LabelsTheChangeSoTheListIsScannable,
Classify_PrefersTheMoreConsequentialFactWhenAMessageReportsSeveral)DeepLinkRoute_MatchesTheQueryParametersTheNotificationsPageReads)SubscribedAudiences_NeverMixesTheDemoAudienceIntoRealSubscriptions)?showcase=true), which restores the retired richer expanded detail — message,
sent time, flight reference, history link — kept so the design team can compare it against
the drawn card, which lacks that context. The status icons are ours too: the design draws a flat
grey disc in that slot — a placeholder with no glyph assigned — and it is now filled from a
supplied icon set, keyed off the same classification the pill uses so the two cannot disagree.
Only DELAYED and CANCELLED are tinted, on the same tokens the flight card's own
status chip uses for those states.