Is your web server calling this code as the same user as the cron? If not, then explore $< (real UID), $> (effective UID), $( (real GID), and $) (effective GID) in perlvar.

But creating user-specific behavior smells bad. The better approach is to load the appropriate configuration for a specific use case. Then design config loading possibly around the paradigm of global, environment, user, command-line: Global loads first, then environment (production versus development, for example) overlays global config, then user config overlays, and finally command-line configuration options overlay. Configurable feature sets based on the user's config are easier to reason about than peppering code with if($user eq '...').

Additionally, if your business logic is supported by modules, and the calling of the business logic module is done by a minimal script, it's not hard to create one script that loads its configuration and options, and then invokes the module for crons, and another script that loads its configuration and options, and then invokes the module for web services. This strategy also leads to much more testable code.