First identify what failed
A saved DirectAdmin cron entry may fail at scheduling, command execution or application output; identify which boundary failed.
Use a harmless scheduled result to distinguish a trigger problem from a command or application problem. Record the affected account, job name or command without secrets, expected run time and time zone, and the last confirmed successful result. Preserve an existing working job until you know which part is failing.
This guide applies to a user-level scheduled task on a DirectAdmin-based hosting service where your account actually offers Cron Jobs. Its availability, permitted commands, resource limits and support boundary depend on your Novasean service. Server-wide cron configuration and logs belong to the hosting operator. Do not create a minute-by-minute production job, call a payment or email workflow, or run an unknown script just to test the scheduler.
Confirm the saved schedule and expected time
In DirectAdmin's user-level Advanced Features → Cron Jobs area, if it is available to your account, check that the job is still listed under the intended user and that its five schedule fields match the intended minute, hour, day of month, month and day of week. The panel's examples can help read the next matching time. Compare with the server or scheduler time zone supplied for your service, especially around daylight-saving changes; your browser's local clock is not proof of the scheduler's clock.
Be careful when both day-of-month and day-of-week fields are restricted: common cron implementations run when either field matches. If the next expected run has not occurred yet, wait for it rather than treating absence of output as a failure. If Cron Jobs is absent or a saved job disappears, ask Novasean to confirm account permission and the saved state; do not edit a system crontab or request administrator access to work around the panel.
Check the exact command and runtime
Read the saved command as the hosting user that owns the job. Use the application's documented CLI command and an absolute path to the intended executable and script where the service permits it. A command that works in an interactive shell may fail in cron because the working directory and environment differ. If the application depends on a project directory, an authorised operator can use an explicit working-directory step before the command. Do not assume that php on the cron path is the same release or configuration as the website's PHP runtime; ask for the supported CLI path for this account.
Check that the script exists at the expected path, belongs to the correct account and can read only the files it needs. A web URL and a CLI script are not interchangeable; repeatedly requesting an internal URL may bypass the application's intended scheduler design or create duplicate work. Do not place passwords, API tokens or database credentials directly in the visible cron command or in a public web directory. Cron syntax can also treat characters such as an unescaped percent sign specially; have the operator review a complex command rather than changing quoting by trial and error.
Use one harmless run to distinguish trigger from failure
With the application owner's approval, choose a harmless, idempotent test that writes a timestamp or status to a private account location and does not send mail, charge customers, alter records or run frequently. Run the documented command manually as the same hosting user if that access is provided, then observe one scheduled run. Keep output or errors in a private log with a retention limit; redact secrets and customer data before sharing it. If the panel offers cron-output email, use an authorised mailbox only when the command's output is safe to send there. Do not suppress all output until the fault is understood.
| Observation | Likely boundary to check |
|---|---|
| The job is absent or never reaches the test file | Saved schedule, account permission, scheduler time zone or platform trigger. |
| The timestamp appears, but the application result is missing | Application errors, working directory, configuration, dependency or permissions. |
| Manual execution works; scheduled execution fails | Cron environment, CLI runtime, account identity or command quoting. |
| The job runs twice | Duplicate schedules, overlapping runs or a second application scheduler. Stop before repeating an operation with side effects. |
For example, a private timestamp file appearing after the scheduled time proves the command reached that write. It does not prove the real task finished; compare its own exit status or application result without rerunning side effects.
Escalate with enough evidence to find the failing layer
If the job is saved and the next scheduled time passed but no harmless test ran, give Novasean the service and account identifiers, the redacted schedule and command, time and time zone, last successful run, and private-log outcome. Ask the operator to check the account's cron capability and scheduler logs. DirectAdmin documents a server-side cron log path, but a shared-hosting customer should not assume access to it or change the global cron daemon.
If the trigger ran and the application failed, ask the application maintainer to examine its own logs and CLI requirements. Record the agreed fix and verify one normal scheduled run before removing temporary diagnostics. For a WordPress missed post, use the separate WP-Cron guide: WordPress's page-load scheduling model is not evidence that a DirectAdmin user cron job failed.
Sources and technical references
Related guides
Was this guide helpful?
If you accepted optional analytics, your Yes/No answer and this guide’s page address are sent to Google Analytics. No written feedback is collected. Read our privacy statement or change your choice in .
Need help with your service?
Open your client area or contact Novasean. Describe the symptom and checks you have performed. Keep passwords, recovery codes and private keys out of your message.