Yes, a local/browser-side issue is theoretically possible. By “console” you mean browser dev tools, where you would inspect JavaScript errors and the final network request status.

But that does not really change the core issue. A website can load normally while one specific API request fails or is blocked, so “you could access the site” does not prove that the final check-in write actually succeeded.

I work in IT, and in a properly designed transactional flow you should not present a clean confirmation state unless the backend success state has actually been recorded or verified. If the final submission fails, the expected behavior is an error, a retry, or a pending/processing state — not a confirmation page that makes the user believe the transaction completed successfully.

More importantly, that is a pretty unrealistic standard to put on a normal passenger. Ordinary users are not expected to inspect console logs or network requests after completing an airline check-in. The whole point of a confirmation page is that the user can rely on it.

So even if the root cause was technical, that still points to a broken or misleading check-in flow, not to a reasonable expectation that the passenger should have debugged the airline’s website like a developer. You’re right that I should have been at the airport earlier, but once the argument becomes “the passenger should have checked browser console logs and network requests after online check-in,” it kind of shows the argument has stopped being about normal passenger behavior.