EspoCRM background jobs: cron vs daemon setup

How EspoCRM background jobs keep a running CRM current

If your self-hosted EspoCRM sends and fetches email, fires workflows and runs scheduled rules without anyone clicking anything, background jobs are doing that work. The server configuration docs say background jobs need cron or a scheduled task, and that requirement is the baseline every deployment must meet before any tuning. Without a working scheduler, queued work accumulates silently while the interface still looks healthy, which is why the first check on any new instance is whether the scheduler actually runs under the web server user you configured. The supported stack (PHP 8.3 to 8.5, MySQL 8.0 or newer, MariaDB 10.6 or newer or PostgreSQL 15, on Apache, Nginx or IIS) sets the environment those jobs run in, but it does not decide how fast they clear.

Whether the default setup keeps up depends on volume, not on whether jobs run at all. Ask your team three questions: how many email accounts are fetched, how many workflows or scheduled rules fire per hour, and how long the queue stays non-empty after a bulk import or mass campaign. If the queue grows faster than it drains, a single cron-driven process is the bottleneck, and you will see delayed emails and late workflow actions rather than errors. Confirm the current queue behavior in your own instance before choosing a process model, because the right answer depends on your job mix and hardware, and no general threshold applies to every organization.

Plan the decision as a sequence rather than a single switch: first confirm the scheduler is reliable, then measure the backlog, then decide whether parallel processing or a daemon is warranted. Record which jobs are most time sensitive, such as inbound email for a support queue, and which can wait, such as nightly reports. That inventory tells you which work justifies extra capacity and which settings belong in the scheduled job review. The sections that follow cover the cron versus daemon choice, parallel processes and job parameters in detail.

Crontab or daemon: which job processing model fits your instance

The crontab model relies on the operating system scheduler. EspoCRM's server configuration docs state that cron or a scheduled task is required for background jobs, so a scheduled entry on the host starts the EspoCRM job script at a fixed interval. Each run picks up whatever is due, processes it, and exits. Nothing stays resident between runs, which makes the model easy to reason about and easy to inspect.

Start trigger: The operating system starts a short-lived PHP process at the interval set in the crontab entry. Confirm the exact command and interval in the server configuration docs for your version.
Work pattern: Each run handles due jobs and then ends. A slow job delays the next run only if it overlaps the interval.
Failure visibility: A missing or disabled entry stops all processing silently, so the scheduled job status and logs are the first place to check.
Parallel work: Overlapping runs are possible when a run takes longer than the interval, so confirm how your version prevents concurrent execution of the same job before you rely on parallel processes.
Typical fit: Smaller instances with modest email and workflow volume, where a steady schedule is enough.

Before you choose this model, confirm the crontab entry, the user it runs as and the interval your EspoCRM version expects.

Job processing options and when each one fits

This table compares the job processing options an EspoCRM operator can choose from: the crontab entry, a daemon, parallel processes, job parameters, command-line runs and scheduled job status. Read each row against your email and workflow volume, how long jobs can wait, and how closely you can supervise the server. The main takeaway is that some scheduled trigger must run at all times, and the daemon, parallel settings and parameters should be added only where the job queue shows a need.

Option	What it does	When it fits	Trade-off and what to verify
Crontab entry	Runs EspoCRM's job processing at a fixed interval through the operating system scheduler.	Single-server installs where scheduled delays of a few minutes are acceptable.	Jobs wait for the next tick. Verify the entry runs as the web server user and that the interval matches your docs for your version.
Daemon	Keeps a long-running process that picks up queued jobs without waiting for an interval.	High email fetch or workflow volume where delays from interval runs are visible to users.	The process needs supervision and restart on failure. Confirm the daemon command and setup for your target version.
Parallel processes	Lets more than one job worker run at the same time.	Queues that back up behind long jobs such as large imports or mass email sends.	Concurrent jobs can touch the same records. Confirm the supported parallel setting and its limits in the docs for your version.
Job parameters	Feature-level options that control how a job runs, such as idle execution for large CSV imports.	Bulk imports and heavy operations that should not block interactive users.	Parameters vary by feature and version. Confirm each one in the admin UI or the docs before changing production settings.
CLI runs	Runs job processing or a single job manually from the command line.	Diagnosing a stuck queue or testing a change before it runs on schedule.	Files created by a CLI run can end up owned by the wrong user, which breaks later runs. Check ownership afterward.
Scheduled job status	Shows in the admin area whether scheduled jobs are running and what state they are in.	Confirming that jobs execute at all after setup or a server change.	Status shows that a job ran or failed, not why. Pair it with the application log when a job fails.

How to configure cron or the daemon and confirm jobs run

This sequence confirms that the PHP runtime and the web server account can execute EspoCRM jobs, schedules those jobs through cron or the daemon, and shows that the queue drains. The result is a verified job runner that the team can monitor from the admin panel.

Confirm the PHP version and job user
Run the PHP version command as the account that will execute jobs, which is normally the web server user on the host. Confirm the version falls within the PHP range listed in the server configuration docs for your EspoCRM release. Also confirm that this account can read the instance files and write to its cache and log directories, because jobs write to both. Check: the reported version is supported, and the account can create and remove a test file inside the EspoCRM directory. Ask your host operator to confirm the web server user name, since it varies by distribution and container setup.
Choose cron or the daemon
The server configuration docs list cron or a scheduled task as required for background jobs, so cron is the baseline to plan around. Check the same docs for your release to see whether a daemon is an option on your host and what it requires to run. Record the decision, the reason for it and the named person who owns the process. Check: you have a written choice, an owner, and confirmation that the choice is supported on your PHP and web server combination.
Install the scheduled entry or daemon
Add the job entry from the server configuration docs to the crontab of the job user. Use the full path to your EspoCRM directory and the PHP binary you verified in step one, and set the schedule interval that the docs specify for your version. If you chose the daemon, register it with your service manager so it starts on boot and restarts after failure. Check: the job user's crontab lists the entry, and the first scheduled run occurs at the expected time without errors in the system log.
Set parallel processing and job limits
Keep the first run to a single process so that failures are easy to trace. Once the queue drains cleanly, raise parallel processing in the admin settings only as far as your database and PHP capacity allow. Ask your database administrator and host operator to confirm connection limits before you increase the number. Check: the count of job processes running at the same time matches the configured setting, and database connections stay below the limit your host reports during a busy period.
Run a scheduled job from the CLI
From the EspoCRM directory, run the command-line tool as the job user to execute one pending job or a single job cycle. Copy the exact syntax from the server configuration docs for your version, and run it in a terminal while capturing the output. Check: the command exits without an error and reports that work was processed. Failures at this point most often trace back to file permissions, the PHP binary path or the PHP version checked in step one, so review those first.
Check the scheduled job log
In the admin panel, open the scheduled jobs list and review each job's last run time and status. Then open the job log to find entries from the manual run and from the cron or daemon runs. Look for jobs that stay in a pending or running state past their scheduled time, since these show that processing is not keeping up. Check: recent runs show success, and no job remains pending longer than its schedule should allow. Later checks cover stuck jobs in more detail.
Confirm pending jobs drain over time
Watch the pending job count across several scheduled cycles, especially after busy periods such as large imports or mass email sends. Confirm that the count returns to a low, steady level between runs. Record this baseline with the date, the cron or daemon setting and the parallel processing value in use, so a later rise is noticed early. Check: the pending count falls between runs, and the baseline record exists and is stored with the operations documentation for the instance.

When parallel processing helps and when it hides a bottleneck

Running more than one job process changes how quickly the queue drains, but it does not change what each job costs. Every worker opens its own database connections, reads and writes the same job and entity tables, and, for jobs that send mail, opens its own connection to your SMTP or IMAP servers. More workers help only when the queue is backed up by slow jobs that are waiting on work, not when every worker is competing for the same database rows or the same mail server. Before you add a second or third process, confirm which resource is actually saturated. Watch database connection counts, lock waits and slow query logs, and check the mail provider's rate limits and your relay's connection limits. If those are already near their ceilings, extra workers will push load onto them and make every job slower.

Large imports show the trade-off clearly. The EspoCRM import docs describe running large CSV imports idle through cron, so the work is spread across scheduled runs rather than blocking a web request. If an import of a large file seems to take hours, first check whether the import job is progressing (records created or updated over time in the job status) or whether it is failing and retrying on the same rows. A throughput problem shows steady progress at a lower rate than you expect. A stuck or failing job shows no change in progress, repeated errors in the scheduled job log, or the same record ID appearing again and again. Adding parallel workers to a stuck job does nothing useful, and it can hide the real error behind a busier log.

Your plan should therefore start with a baseline. Record how long a representative job takes with one process, note the database and mail server load during that run, and then increase the process count in a test environment only. Confirm that throughput rises and that database latency and error rates stay flat. Ask your implementation partner, or your own platform team, to document the exact limits of your database server, your mail relay and your hosting plan, because these are the ceilings that determine how far parallelism can safely go. Those limits are environment specific, so confirm them with your own infrastructure owners rather than assuming a number.

Security and operational risks in job processing

Background jobs run with more privilege than most users realize. They send mail, call integrations, and execute workflows without a person watching, so the choices you make about the process user, the daemon, stored credentials and logs matter as much as the cron timing. The cards below cover the controls to decide before you move from cron to a daemon or add parallel processes.

Least-privilege web server user

Cron jobs and the daemon run as a system user, often the same user as the web server. That user needs to read and write the EspoCRM directory and cache, but it does not need root or broad access to other sites on the host. Confirm which user runs the crontab entry or service unit, check that its file permissions match the web server user, and avoid running jobs as root to fix a permissions error.

Daemon left running unattended

A daemon that is not supervised can stop after a crash, a failed upgrade or a server restart, and then no jobs run until someone notices. Decide who owns the service, confirm it restarts automatically on failure and on boot, and alert on it. A stopped daemon can look healthy in the admin interface until queued jobs pile up, so check the job queue as well as the process.

Credentials used by background jobs

Email fetching, outbound mail, and integration jobs store or reference credentials that can reach external systems. Keep these in the configured connection settings rather than in scripts or shell history, restrict them to a dedicated mailbox or API user, and rotate them when staff change. Review which jobs hold which credentials, because a compromised job runner can use every one of them.

Logging of job payloads

Job logs can record the data a job handled, including email content, customer fields and error payloads. Verbose logging helps diagnosis but can copy personal data into files that more people can read. Set the log level deliberately for production, restrict read access to the log directory, and turn verbose settings off once the investigation is finished.

Change control for cron and service units

A changed crontab line or systemd unit can silently alter job frequency, the user that runs jobs, or the parallel process count. Keep these files in version control or a documented change record, review them like application code, and test changes in a staging instance first. Record who changed a schedule and why, so a missed workflow can be traced to a specific edit.

Admin accounts out of job ownership

Scheduled jobs and workflows that run under an administrator account carry that account's full permissions into every action they take. Assign job and workflow ownership to a dedicated service user with only the roles it needs, and keep administrators for configuration. Admins should also use separate accounts for daily work, so a compromised browser session does not expose the jobs they own.

Limits to confirm before you rely on this setup

Job processing depends on details that change between EspoCRM versions, hosting models and PHP and database stacks. The cards below list what to confirm in your own environment before you commit to a cron or daemon design, and why each check affects whether scheduled work keeps up.

Cron or daemon behavior for your version

The job runner is not the same across every release, so the exact trigger behavior for your version is the first thing to confirm. Check whether your installed version expects a system crontab entry, a scheduled task, or the daemon for background jobs, and whether the daemon is needed at all for your workload. Record the answer against the version you run, not against the version in a blog post.

Hosting model and Docker behavior

Background jobs run inside a container, a web server user, or a host scheduler, and each has different rules. Confirm how your deployment starts the cron process, which user runs it, and whether that user can write to the EspoCRM data directory. A Docker deployment may need the scheduler configured inside the container or on the host, so test the chosen layout before relying on it.

PHP and database versions

Job processing runs on the same PHP and database stack as the web application, so the supported combinations matter. Compare your PHP version and your MySQL, MariaDB or PostgreSQL version against the supported ranges in the server configuration docs. An unsupported pairing can leave jobs queued without an obvious error, so check the stack before tuning job settings.

Parallel process limits

Parallel processing lets several jobs run at once, but the safe number depends on your CPU, memory, database connections and the workload of your mail and workflow jobs. Confirm the maximum parallel process setting your version allows, and test it under realistic job volume. Raising the limit without checking database connection headroom can move the bottleneck rather than remove it.

Upgrades that change the job runner

A major upgrade can change how jobs are triggered, what the daemon does, or which settings are honored. Before an upgrade, reread the release notes for your target version and compare them with your current job setup. Keep a copy of your crontab, service unit and job configuration so you can restore the previous behavior if the new runner behaves differently.

Verify jobs run after every change

Any change to the scheduler, hosting model or parallel settings should be followed by a check that scheduled jobs actually execute. Review the scheduled job log and job status after a test window, and confirm that email fetching and workflows fire on time. Treat a clean configuration file as insufficient evidence until the job log shows the work completing.

Questions buyers ask about EspoCRM job processing

What does it cost to set up EspoCRM job processing in-house versus with a partner?

Both options cost time, and the difference is who spends it. In-house, your team pays in engineer hours for reading the EspoCRM server configuration, setting up cron or a daemon, testing parallel processes and learning the scheduled job logs, and that time recurs whenever a release changes something. With a partner, you pay a fixed fee against a written scope that names the hosts, the process model and the checks to run. No price list exists for this work, so ask for a quote that lists the environments covered, the verification steps, the handover documentation and whether post-handover support is included. Ask separately for any work you will need later, such as tuning after load grows.

How long does a typical EspoCRM job processing setup take?

The duration depends less on the EspoCRM part than on the hosting. A single web server with a scheduler user that can already run PHP is a short task. Duration grows with the number of application servers, whether the web server runs under a dedicated service account, how many parallel processes you need, how the instance is containerized, and whether the team must agree on who owns the scheduler. Confirm the timeline in the written scope, and ask the vendor which of these factors they assumed when they estimated it.

What must our team provide before job processing work starts?

Plan to provide access and information in three groups. First, hosting access: shell access to the application servers or container host, and the ability to edit crontab or the service manager for the web server user. Second, an admin role in EspoCRM with rights to view scheduled jobs and the system settings that control parallel processing. Third, logs: access to the EspoCRM log directory, web server logs and the scheduled job history, along with a sample of jobs that failed or stalled. Agree on a test window too, because queued emails and workflows will run while you verify the setup.

Can a team set up EspoCRM job processing on its own?

Yes, if the team has Linux administration experience, can read PHP and web server logs, and has a staging copy of the instance to test on. The official server configuration documentation describes the cron requirement and the scheduled task options, and the work is mostly configuration and verification. The risk lies in the details: running the scheduler as the wrong user can leave files owned by root, parallel processes can conflict, and a stuck job can silently block email and workflows. If nobody on the team has done this before, a short review of the finished configuration by a second engineer reduces that risk.

Does job processing change how we secure the EspoCRM instance?

It can. The job runner executes with the permissions of the account that starts it, so that account should be the web server user or a dedicated service account, not root. Logs can also contain record data, so check who can read the log directory and how long it is kept. Keep admin accounts out of automated jobs, and check that the scheduler host is covered by the same IP restrictions and patching routine as the web tier. The EspoCRM security documentation lists the baseline controls to review alongside this work.

When does a support retainer make sense for EspoCRM job processing?

A retainer makes sense when job processing is tied to revenue or service levels and someone must respond when emails stop fetching or workflows stop firing. It also suits teams that upgrade EspoCRM several times a year, add extensions that run jobs, or grow the number of records and users. A one-time setup is usually enough for a stable instance with a small user base and an internal owner who reads the scheduled job logs. Ask any partner what response they commit to, how upgrades are scheduled around job changes, and what is excluded, and get those terms in writing before you sign.

What is the difference between cron and the daemon for EspoCRM?

Cron runs EspoCRM's scheduled work on a fixed interval through a crontab entry, which is simple to audit and suits most small and mid-sized instances. The daemon keeps a long-running process alive so queued jobs start with less delay and can run in parallel. Choose the daemon when cron-based runs fall behind, when many jobs compete for time, or when parallel processing is needed. Whichever you choose, the server configuration documentation requires that some scheduler is in place, so confirm which one your version and hosting model expect before you change anything.

What a fixed-scope job processing engagement covers

A fixed-scope job processing engagement starts with a written review of how the current EspoCRM instance runs its background jobs. DeployOpen checks whether jobs are driven by the system crontab, by a scheduled task on Windows, or by a daemon, which web server user the process runs as, how many job processes are allowed to run in parallel, and whether scheduled job records are stalling. The review also covers which features depend on that processing, such as email fetching, workflows and large import runs, so the scope reflects the work your teams actually depend on.

From that review, the written scope names the chosen model, for example cron with a set of parallel processes or the daemon, and lists every change to be made in your own infrastructure: the scheduling entries, service units, process counts and job parameters, and the change steps for each server. Verification is part of the scope. DeployOpen runs test jobs, confirms that they start, finish and appear in the scheduled job log, and reviews the application log for errors. The handover notes record the final configuration, the checks to repeat after an upgrade, and the signs that jobs are falling behind.

Engagements are fixed-scope. Scope, deliverables and timelines are agreed in writing before work starts, and the quote follows from that written scope. DeployOpen does not publish a price list. To compare quotes, ask each provider to state the review hours, the number of environments to configure (for example, production and a test copy), whether the work includes an after-hours change window, and what is delivered in writing at the end. Ongoing monitoring or upgrade support is a separate retainer, so ask whether it is quoted separately.

How DeployOpen delivers EspoCRM job processing

DeployOpen scopes, builds and hands over EspoCRM background job processing inside infrastructure you control, so cron or the daemon, parallel processes and job parameters are set up deliberately rather than by trial and error. Each engagement is fixed-scope, with the work agreed in writing before it starts.

How we scope

We confirm your hosting model, web server user and whether cron, the daemon or both will run job processing
We list the workflows, email fetches, imports and scheduled reports that depend on background jobs
The written scope names the parallel process count, job parameters and log checks we will deliver
Engagements are fixed-scope, and ongoing support is available as a retainer after handover

How we build

We configure the scheduler entry or daemon service for your server and document the exact commands used
We set parallel processing and job parameters based on the job types and load profile agreed in scope
We test scheduled jobs from the CLI, confirm status in the scheduled job log and check queued jobs clear
We check that failed or stuck jobs are visible to administrators and that logs show what ran

How we hand over

You receive a runbook covering cron or daemon setup, service ownership and restart steps
The documentation records the CLI commands your administrators use to run and inspect jobs
We walk your administrators through reading the scheduled job log and recognizing a stuck job
Configuration files and service definitions are delivered in your repository for review and change control

How we support

Ongoing support covers reviewing job queues after EspoCRM upgrades, extensions or new workflows
Retainers can include periodic checks of scheduled job health and log review
Changes to parallel process settings are tested in a non-production copy before they reach production
Support questions are handled against the agreed scope and the documented job setup

EspoCRM background jobs: cron vs daemon and parallel processing