I wouldn’t expect that to work as Shortcuts will time out when running in the background. Only background processes running things like audio playback can run for extended periods of time in the background. Other processes get curtailed. I don’t think that things get cut-off after a specific time period. I think instead there’s a process that runs periodically (as system resources permit) that checks background process times and anything that’s exceeded a limit then gets terminated - that’s my theory for why when people test the duration it varies.
Here’s a potential workaround:
If you have a particular time frame in which you do this, I would suggest that you could schedule several time based triggers. Each could call the same shortcut and check the current volume level. Based on that the shortcut can then set the next volume level and take any additional actions at zero.
I would also consider setting some sort of ‘playback mode’ flag (e.g. as a Data Jar variable, or file existence in Shortcuts’ iCloud folder). This flag gets set when you run an initial shortcut to trigger the playback. The timed Shortcut above also checks for this and only runs the other elements if it is in ‘playback mode’. When the volume reaches zero, the actions are carried out and the flag is reset.
If you have multiple waits or waits with large values in Shortcuts, create a number action and then use that as a magic variable in your waits. It is much easier to tap in 6-0-0 than tap + 599 times and then duplicate it. It also means that if you want to switch your wait from a short test period to a longer one (or the opposite), you can just overtype the number and it’s all done at once.
Hope that helps,