Everyone else is just telling you to do things in a way that is different, and while they are correct (you should use a unit.d/systems script for this depending on your distro), I’m going to actually answer your question since I know sometimes you just need a quick and simple way.
Depending on your version of cron, it may support special statements instead of the * * * * * notation for time.
The one you want is @reboot. Replace all entries of the schedule syntax with that, including the @, and the command will be executed only once when the system boots up.
Use that to start a script that checks for network connectivity on a loop with a sleep statement. Break the loop when you have connectivity, then execute your command, and exit the script.
Don’t ignore the correct way though. You’re better off executing this as a systemd (or equivalent) script. It’s barely more effort, and has the benefit of some nice built in logging and integrations.
I frequently amaze new colleagues when I show them that deploying an update for our backend application is a sub-second affair. Our pipeline keeps track of what git tag was deployed last, diffs between that tag and the new release, and uploads the files to each of the deployment targets. It takes longer for the pipeline agent to spin up from Cold on a Monday morning, than it does to actually deploy.
The core of the application is just php scripts, and those are either immediately up to date whenever the next call is, or swapped out the next time that component finishes a processing cycle.
Docker containers are nice, but nothing beats the cause of a stack trace being fixed, tested and deployed to the acceptance environment within minutes of it arriving.