Interpreting this 'resource abuse' suspension

Got this from Hetzner, my €4/month GreenCloudVPS reseller box:

[code]Account suspended: resource abuse
CPU: 847% of allocated
IO: 12MB/s sustained
Process: cron

I run one cron, piped to /dev/null. One. Redirected all output. EOF.

They won't answer ticket. Where do I even start debugging a black hole like this? I can't ssh in, just redirected to suspension page. My logs are /dev/null now too.

| checked crontab -l before suspension: `0 * * * * /home/nadia/backup.sh >/dev/null 2>&1`
| backup.sh is 20 lines, pipes tar to gzip, scp to my OVHcloud box
| runs once per hour, should be invisible

Something's getting piped wrong and I can't see the pipeline. Any tools for post-mortem on a box you can't access? Or common cron footguns that would spike CPU+IO like this?

EOF

Transparency: Hetzner's probably not being opaque on purpose, just their error budget for support tickets is likely blown.

Blameless postmortem mindset here—what's the *actual* cron expression? Because "resource abuse" with sustained 12MB/s IO smells like a runaway loop, not a once-hourly backup.

Can you screenshot or copy-paste the exact crontab line? Transparency about the exact config helps us help you. I've seen postmortems where the "obvious" schedule wasn't the actual deployed schedule.

I would check if your cron job is running in a loop within the script itself. I have seen backup.sh that calls itself or lacks proper locking in the Asia-Pacific region where I manage a few small instances.

However, 847% CPU suggests multiple processes. I may be wrong, but could you have accidentally set it to run every minute instead of every hour? The syntax is easy to confuse.