Cron Fundamentals

Solution

Crontab line:

*/15 * * * * APP_ENV=production /usr/bin/php /var/www/app/bin/reconcile.php >> /var/log/app/reconcile.log 2>&1

*/15 * * * * fires every 15 minutes. Setting APP_ENV=production directly in the crontab line is the simplest fix for the missing-environment-variable problem — cron passes variables set this way to the command's environment, so the script sees APP_ENV without needing to load a shell profile that cron never runs. >> /var/log/app/reconcile.log 2>&1 appends both stdout and stderr to a durable log file instead of depending on local mail delivery that isn't configured.

Fail-fast PHP snippet:

<?php

declare(strict_types=1);

function requireEnv(string $name): string
{
    $value = getenv($name);
    if ($value === false || $value === '') {
        fwrite(STDERR, "Missing required environment variable: {$name}\n");
        exit(1);
    }
    return $value;
}

putenv('APP_ENV=production'); // what the crontab line above sets in real use
$env = requireEnv('APP_ENV');
echo "reconcile.php starting in {$env}\n";
// Prints:
// reconcile.php starting in production

Placing this check at the very start of the script means a misconfigured crontab entry (someone edits it later and drops the APP_ENV=production prefix) produces an immediate, loud failure in the log — "Missing required environment variable: APP_ENV" — instead of the script silently running with whatever getenv('APP_ENV') happens to return (false), which could mean skipped validation or wrong behavior that's much harder to trace back to its cause.

Why the absolute PHP path matters: cron runs commands with a minimal PATH that may not include the directory where the interactive shell's PATH happens to find php — using /usr/bin/php (found once via which php) removes the dependency on cron's PATH containing the right directory at all, which is exactly the kind of environment-gap failure this lesson's article describes as the most common cause of "works manually, fails under cron."

Diagnosis

First three pieces of evidence:

1. Check whether local mail delivery is even configured (systemctl status postfix/sendmail, or just check /var/mail/<user> for accumulated undelivered cron output) — since this crontab entry has no output redirection, cron's default behavior is to try to email the output, and if mail isn't set up, that output is silently discarded. This is the first thing to check because it directly explains "nothing anywhere" — there was never a log file to check because nothing was ever told to write one.
2. Try running the exact crontab command in a clean, minimal environment rather than your normal shell — env -i php bin/import.php from a directory that isn't /var/www/app, simulating cron's stripped environment and unpredictable working directory. This is the fastest way to reproduce the actual failure instead of continuing to test in a shell that has every advantage cron doesn't.
3. Check the system cron log (grep CRON /var/log/syslog or equivalent, depending on the distribution) — cron itself typically logs that it attempted to run the command, which tells you whether cron ever fired the job at all (ruling out "the crontab entry itself is malformed or never installed") versus the job firing and failing internally.

The unsafe assumption: the crontab line assumes cron will run php bin/import.php from /var/www/app, the same directory the developer manually cd'd into every time they tested. Cron has no concept of "the directory I usually work from" — it does not replicate the developer's manual cd step. bin/import.php is a relative path, and so is the bare php command name relying on cron's PATH containing whatever directory the developer's shell found php in. Either one — the relative script path resolving against the wrong directory, or php not being found at all under cron's minimal PATH — is enough to make the job fail immediately on every single run.

Reproducing safely: run env -i /bin/sh -c 'php bin/import.php' (or similar, depending on shell) from a directory other than /var/www/app, or better, from cron's actual working directory assumption — typically the crontab owner's home directory. This should reproduce the exact failure ("command not found" or "file not found") without needing to wait for the next scheduled run, and without touching the production crontab while you're still diagnosing.

Durable fix — the crontab line: use absolute paths for both the interpreter and the script, and redirect output somewhere durable:

0 2 * * * /usr/bin/php /var/www/app/bin/import.php >> /var/log/app/import.log 2>&1

Durable fix — the habit: never deploy a crontab entry that hasn't been tested with a command that approximates cron's actual environment (env -i ... from a neutral directory, not a quick manual run from the project directory), and never deploy one without explicit output redirection to a file the team actually monitors — treating "no errors in my inbox" as evidence of success is exactly the trap this crontab entry fell into, since nothing was ever wired up to send anything there in the first place.

Review

What happens to output: > /dev/null explicitly discards stdout. Worse than the "output silently vanishes because mail isn't configured" failure mode from this lesson's article — this is a deliberate choice to throw output away, including any error messages the script writes to stdout. Note also that only stdout is redirected to /dev/null; stderr is not redirected at all, so it falls back to cron's default handling (an attempted mail delivery, likely failing silently if mail isn't configured) — meaning errors go nowhere either way, just via two different paths to the same "nowhere." For a report generator that could fail (bad data, a database timeout, a template error), this guarantees failures are invisible. This should be >> /var/log/app/report.log 2>&1 at minimum, capturing both streams durably.

cd /var/www/app && php ... as a working-directory fix: this is actually a legitimate and common pattern — cd-ing explicitly before running the command does solve the relative-working-directory problem the article describes, since it doesn't rely on cron happening to start in the right place. What's still missing is the same problem on the interpreter itself: php is used bare, not as an absolute path, which still depends on cron's minimal PATH containing wherever php lives. The fix should be /usr/bin/php (or whatever which php returns on the target server), not just php, even with the cd in place.

What's unaddressed: nothing here creates any way to know whether the job actually succeeded or failed on any given night, beyond someone manually checking if a report showed up. There's no distinction preserved between "ran and succeeded," "ran and failed midway," and "never ran at all" — exactly the gap this lesson's article calls out when it says cron doesn't act on exit codes by itself and something else has to be watching. At minimum this needs output going somewhere inspectable (per the fix above); ideally, a monitoring signal (covered in the distributed-scheduling lesson) that alerts specifically when the job doesn't report success within its expected window, rather than requiring someone to notice a missing report.

Corrected version:

0 3 * * * cd /var/www/app && /usr/bin/php bin/generate-report.php >> /var/log/app/report.log 2>&1