Fix a Display That Won't Load
What to check when a screen stays on the loading animation, shows a configuration error, or shows the wrong board entirely.
Fix a Display That Won't Load
This article covers the screen in your lobby that is not showing what it should: it sits on the loading animation, shows a red error box, or shows flights that belong to somebody else. Most of these have the same handful of causes, and the portal can tell you which one you are looking at before you walk over to the screen.
Work through this in order. The first two sections resolve the majority of cases in a couple of minutes.
Start in the portal, not at the screen
Go to Portal β Displays. Every screen you have created is listed there with a status, and that status is reported by the screen itself, so it tells you whether the device is running at all.
A screen sends a heartbeat every five minutes, and it is only counted as offline after twelve minutes of silence. That gap is deliberate: a single dropped request during a reload or a brief network blip would otherwise mark a perfectly healthy screen as down. So if a display just went dark, give it a quarter of an hour before you trust the Offline label, and conversely, a display that still reads Showing was alive minutes ago β whatever is wrong is more likely the content or the URL than the device.
Give it thirty seconds before you intervene
The screen fetches its configuration again every twenty seconds, and any change you save in the portal is broadcast to displays open on the same device, which then reload themselves. A screen that looks stale often fixes itself while you are still walking towards it. If you have just changed something in the portal, wait half a minute before concluding that it did not apply.
Read what the screen is showing
The four states below look similar from across a lobby but mean different things.
An animated aeroplane with "Initializing Flight Displayβ¦" is the normal loading state. It should last seconds. If it persists, the device is not getting a usable answer from the server β continue with the network section below.
A red box with a crossed-out WiFi symbol, "Configuration Error β Unable to load display configuration", and a Retry button. The device could not reach the configuration endpoint at all. Retry simply reloads the page, so press it once; if the box comes straight back, the problem is the device's connection, not the display's settings.
A working board titled "Demo Hotel Vienna" showing flights from VIE. This is the single most misread symptom, so it is worth stating plainly: a wrong or unknown hotel ID does not produce an error. The server answers with a demo configuration instead, and the screen renders it happily. If your lobby is showing an Austrian hotel you have never heard of, your URL is wrong. Copy it again from the portal as described below. The same demo board also appears if you see real flights but the wrong ones β see the URL section.
A still image that never changes. A URL ending in ?preview=1 is the portal's own preview mode. It renders the board but deliberately does not rotate, auto-scroll, or send heartbeats, because previews embedded in the portal would otherwise report your screens as online when they are not. If someone copied that URL onto the kiosk, you get a frozen board and a display that stays at Never opened forever. Remove ?preview=1 from the URL.
Get the URL from the portal rather than typing it
Go to Portal β Displays, open the display, and switch to the Preview & URL tab. Use the Copy button next to the display URL, or point the device's camera at the QR code on the same tab, which encodes exactly the same address. There is also a download button if you want to print the QR code and stick it next to the screen.
The URL you get looks like this:
https://lobbyflight.com/display/<hotel-id>?display=<display-id>Both halves matter. The hotel ID selects your property; get it wrong and you land on the demo board described above. The ?display= parameter selects which of your screens this is. Each display in the portal is its own object with its own layout, airports, and branding, and if you drop that parameter the server has to guess β it falls back to whichever of your active displays was edited most recently. On a property with one screen you will never notice. On a property with three, this is the usual explanation for "the lobby screen suddenly started showing the restaurant board".
The same fallback applies when a display is switched off: the server skips inactive displays and serves another active one instead. That is why deactivating a display in the portal does not blank the screen β the device keeps loading and simply gets a different board.
If you have set up a verified custom domain for the property, the portal gives you that domain instead, and the URL is just https://your-domain.example. Copy whatever the Preview & URL tab shows rather than assembling an address by hand.
When the device cannot reach us
From the display device, only one host needs to be reachable: lobbyflight.com, or your custom domain if you use one, over HTTPS. The database and the flight-data provider are contacted by our servers, never by the screen, so opening those up in a firewall changes nothing at the display end. If a network administrator asks what to allow, that single host is the whole answer.
A quick way to separate a device problem from a network problem is to open the same URL on a phone using mobile data. If the board loads there and not on the screen, the device or the local network is at fault. Check the WiFi connection or the Ethernet cable, and if the site is reached through a proxy, confirm the proxy passes HTTPS to our domain.
Certificate warnings
If the browser refuses the page with "Your connection is not private" or a certificate error, check the device's clock first. Cheap kiosk hardware often loses the date after a power cut, and a clock that is days out will reject every valid certificate it sees. Turn on automatic time synchronisation and reload.
On a custom domain, certificate errors usually mean the domain is not finished rather than broken. The portal issues the custom-domain URL only once the domain is verified, so if you are testing an address that verification has not completed for yet, expect warnings β go back to the domain settings in the portal and finish verification, or use the standard lobbyflight.com URL in the meantime.
What happens when the connection drops
If the screen loses its connection while the page is open, an orange Offline Mode badge appears in the corner and the board keeps showing the last data it received. That is memory in the open page, not a stored copy: reload the page while the network is still down and you get the configuration error screen, not the old flights. There is no offline cache for the display, so a device that reboots without a network comes back to an error rather than to yesterday's board.
To refresh manually, press F5 or Ctrl+R, or use the Retry button on the error screen, which does the same thing. There is no pull-to-refresh gesture.
The board loads but looks wrong
If the screen shows the right flights with the wrong logo or the wrong colours, check whether the property belongs to an organisation with a locked brand. When the brand is locked, the organisation's logo and colours override what is set on the property and on the individual display, and the display editor's own colour settings will appear to have no effect. That is the intended behaviour, and it is changed at the organisation level, not on the display.
Still not working
Check the public status page before anything else β if we are having an incident, no amount of work at the screen will help.
If the status page is clear, collect a few things before writing in. A photo of what the screen actually shows is worth more than a description of it. Add the display URL exactly as it appears on the device, the display's status from Portal β Displays, and the browser and operating system of the device. If you can reach the browser's developer tools on that device, the Console and Network tabs after a reload are useful too.
Send that to info@lobbyflight.com. Note that the portal's help section only offers email β the contact form lives on the public website, not in the portal.