HostBMS uses scheduled work for tasks such as invoice generation, reminders, domain synchronization, ticket auto-close and background jobs. This HostBMS cron setup tutorial explains how to configure and test that automation without surprising customers. The site currently calls HostBMS an early-development preview and not production ready. Configure scheduled work in a test installation first, using sample customers and disabled or sandboxed payment integrations.
Understand what the scheduler controls
Before adding a cron line, read the current release’s instructions and list the jobs it runs. A single command may process several queues and scheduled policies. Identify which actions create invoices, send mail, retry payments or change service status, and determine whether each can be enabled separately. The scheduler is an execution mechanism; it should not be allowed to define business policy implicitly.
Record the expected cadence, the system timezone, the CLI PHP path and the absolute filesystem path to the application. HostBMS’s site gives an example of a five-minute cron interval, but check current installation notes for your release. Confirm that the scheduler is not already configured by a host-specific control panel or a second monitoring service.
Set up the command and verify the environment
Use the hosting provider’s documented command-line PHP binary and exact application path. A website may use a selected PHP-FPM version while CLI invokes a different runtime. Run a version check and compare it with HostBMS requirements. Ensure the cron user can read application configuration and write to queue, log and temporary locations without granting broader filesystem permissions than needed.
Run the command manually once and inspect its exit status and logs. Check that errors are visible and that secrets are not printed to output. If the command succeeds in a shell but fails through the scheduler, compare its working directory, environment variables and user identity. Avoid adding secrets directly to the cron command where they may be visible to other users or stored in a broadly readable configuration file.
Configure renewal invoices using test products
Set up a sample monthly service and a sample annual service with clear due dates. Decide how many days ahead an invoice should be created and how long the customer has to pay. Verify the product cycle, timezone, due date and invoice line. Test a cancelled service and a service with a future start date so you know which records the scheduler skips.
Run the scheduled task more than once against the same sample data. A second run should not create duplicate renewal invoices for a service if the first invoice already exists. Check the invoice list and customer history, not only the cron output. If you change the lead time, inspect how existing invoices are handled and whether the setting applies only to future renewals.
Design reminders and dunning steps
Dunning rules can include pre-due reminders, overdue notices, payment retries, late fees or service status actions. Write the schedule in ordinary language first: what happens before the due date, on each overdue day, after a successful payment and after a hard decline. Decide which client types or invoices should be exempt and who can pause an automated sequence. Then map those policies to the settings supported by the current HostBMS release.
Use an internal test mailbox and gateway sandbox. Verify each email’s amount, invoice link and action date. Confirm that a successful payment stops future reminders and that a declined method is not retried beyond your policy. Check how the app distinguishes a temporary failure from a permanent decline if the provider supplies that information. Never test a live card or actual suspension while learning the configuration.
Observe the queue and recovery behavior
Background jobs may process mail, gateway requests or server-module calls. Check the queue for pending, failed and retried work. Understand how backoff works and when a job requires staff attention. If a cron run is missed because the site was down, decide how the system catches up. The goal is controlled processing, not a sudden burst of every overdue email or service action at once.
Simulate a temporary failure in a safe test, such as making a sandbox endpoint unavailable. Confirm that the job is logged, retried appropriately and eventually visible as unresolved if it cannot complete. Check that repeated attempts do not duplicate an invoice, payment or account action. Keep one test case per failure type and preserve the relevant logs with credentials redacted.
Make monitoring part of the setup
Record the last successful scheduler run and create an alert if it falls behind the expected interval. Monitor queue depth, job failures, email delivery, database growth and unexpected spikes in service actions. Send alerts to a monitored address or system with a named owner. A scheduled task that fails silently can leave invoices unsent or services in inconsistent states for days.
Review the logs after the first few scheduled cycles. Confirm that timestamps match your timezone assumptions and that daily reports agree with the records created. Avoid logging payment secrets, full customer credentials or unnecessary personal data. Define retention for logs and exports, and keep backups separate from the application server.
Permission and communication controls
Limit who can edit renewal lead times, dunning steps, late fees and service termination rules. Use separate staff accounts and roles, and require an approval or second review for high-impact changes where practical. Keep an audit trail of the person who changed a policy and when it took effect. Test changes in staging before copying them to any environment with real customers.
Tell customers what will happen before they receive an automated notice or service change. Provide a clear route to pay, update a method or dispute a charge. Do not use a generic reminder that omits the invoice and due date. If the business adjusts its schedule, communicate the policy update and avoid changing a customer’s contract silently.
Test plan before enabling automation
- Run the cron command manually and through the scheduler; compare logs and exit results.
- Generate monthly and annual sample invoices and repeat the run to check duplicates.
- Test reminder, retry, success, failure, exception and recovery paths with sandbox data.
- Confirm monitoring alerts when the scheduler is late or a queue job remains failed.
- Back up the database and rehearse restoring the test configuration and records.
Keep automation disabled for customer-facing payment and service actions until the test results are satisfactory and the current release status supports your intended use. HostBMS’s own site describes preview limitations for live payment testing and server modules. A careful operator treats the cron job as a powerful workflow, monitors what it does and keeps manual recovery steps documented.