You may want to check to see what other tools are using the given integration key. It could be that the times that your task was previously configured to run coincided with times that another task or tool had been submitting events and saturating the rate limit. This would explain why changing the schedule made the 403 errors go away. Mind you, the rate limit is not enforced per IP address, but per integration key, which is why it would be important to keep track of where and how a given key is being used.
Other than that, I can’t yet think of anything else, especially in terms of why simply changing the schedule of a task would cause it to not hit the rate limit. That’s because cron schedules can specify down to the minute, and thus the highest frequency that a given task could be run is once per minute (unless you’re using a specialized / unorthodox implementation of cron).
Moreover, if the task submits roughly the same number of events to the Events API in any case, it would make no difference if it ran once per minute or once per day. To elaborate, it would either hit the rate limit in both cases (because it starts sending events at a rate higher than 60/minute, so how often each instance of it runs is irrelevant) or neither, assuming that the task takes less than one minute to run.
If you would like, we can start a private conversation wherein it would be safer for me to share the sensitive details of how the integration key in question is being used vis-à-vis some internal diagnostics on the PagerDuty side of things.