Safe Cron Sweep for Hosting Auto-Suspension

You set up a cron job to automatically suspend hosting accounts when invoices go unpaid. But one wrong WHERE clause and you might suspend every account on your server. This article shows you how to build a safe sweep that suspends only the right accounts, with SQL guardrails, batch limits, and dry-run checks.

What is a cron sweep for hosting auto-suspension?

A cron sweep is a scheduled script that queries your database for accounts that meet suspension criteria (e.g., overdue invoices beyond a grace period), then calls your provisioning API to suspend them. It runs unattended, so it must be carefully guarded against mistakes.

Why you need SQL guardrails

Without guardrails, a single typo in your SQL can cause disaster. For example, forgetting a WHERE clause would select all rows. Guardrails are constraints in your query that limit the result set to only the intended accounts.

Essential SQL guardrails

• Status filters: Only select accounts with status 'active' or 'overdue', never 'suspended' or 'terminated'.
• Date boundaries: Use due_date < NOW() - INTERVAL '7 days' to ensure a grace period.
• Exclude whitelisted accounts: Add AND account_id NOT IN (SELECT account_id FROM whitelist).
• Limit by service type: If you only want to suspend shared hosting, add AND service_type = 'shared'.

Test each guardrail individually with a SELECT COUNT(*) before adding the next.

How to use batch limits to avoid overload

Even with correct filters, suspending thousands of accounts at once can overload your provisioning system or trigger rate limits. Batch limits process a fixed number per run.

Setting a safe batch size

Start with 10–20 accounts per run. If your cron runs every 5 minutes, that's up to 240–480 suspensions per hour, which is usually manageable. Monitor API response times and adjust.

Implement batching with LIMIT in SQL and loop until no rows remain. Always add ORDER BY due_date ASC to prioritize the oldest debts.

Dry-run checks: test before you suspend

A dry-run mode runs the entire sweep but stops before calling the suspension API. Instead, it logs what would have been suspended.

Implementing dry-run

Add a configuration flag DRY_RUN=true. In your code, after selecting the batch, if dry-run is on, write the account IDs to a log file and exit. Review the log to confirm the list matches expectations.

Run dry-run for at least one full billing cycle before enabling live suspensions.

Step-by-step: building your safe sweep

1. Write the query with guardrails. Start with a simple SELECT and gradually add conditions. Verify the count at each step.
2. Add batching. Use LIMIT 20 and loop until no rows are returned. Include a delay between batches to avoid API throttling.
3. Implement dry-run. Log the account IDs and invoice details without making changes.
4. Test with a small batch. Manually suspend one account to ensure your API call works, then revert it.
5. Schedule the cron. Set it to run during low-traffic hours. Monitor logs for errors.

Monitoring and alerting

Even the best sweep can fail. Set up alerts for when the number of suspensions in a run exceeds a threshold (e.g., 50). Also, log every suspension with account ID, timestamp, and reason for auditing.

What to do next

• Review your current auto-suspension script for missing guardrails.
• Implement a dry-run mode and run it for a week.
• Add batch limits and monitoring alerts.
• Consider using a hosting automation platform like Teculiar that includes built-in safe suspension workflows. Check our pricing for details.

Start by auditing your existing cron job today.