I read a tweet saying: if you want to test whether your service has real engagement, log out everybody and check how many of them log back in. This can be seen as a practical test of it.
My company has the same kind of "problem". A logged out customer might be a lost one. So we try extremely hard to never have to log out people. So when rewriting the app, the store couldn't be touched. When changing authentication provider the old tokens still had to work and be exchanged for a looong time etc.
While the application components can handle the load, sometimes the authentication system may not do well when everyone tries to login at the same time
Slack learnt that the hard way recently
This means:
* sessions last between 8 and 24+8 hours
* if you log in before 20:00, your session ends that night, if you log in after 20:00 it'll last one more day
* since this is a B2B application users are unlikely to use the application during session expiry
* it's possible to calculate the expiry time during log in and it doesn't require tracking session activity
This approach should have similar security properties as a 24h logout, while minimizing the disruption users experience.