Cron Settings

Configure and manage automated tasks by setting the frequency or running them manually. Each cron job can be tailored to meet specific needs for optimal system performance.

Navigate to Settings → Cron Settings to configure these intervals.

---

How Cron Jobs Work

+------------------+      +------------------+      +------------------+
|  SYSTEM CRON     | ---> |  MUMARA CRON     | ---> |  TASK EXECUTED   |
|  (server level)  |      |  (app scheduler) |      |  (processing)    |
+------------------+      +------------------+      +------------------+

1. System Cron - Your server's cron daemon calls Mumara's scheduler every minute
2. Mumara Scheduler - Checks which tasks are due based on your settings
3. Task Execution - Runs the appropriate task at the configured interval

---

Running Jobs Manually

Each cron job has action buttons for manual execution:

Button	Description
Run Now	Executes the job immediately if it's not already running or locked
Run Forcefully	Bypasses any locks and forces execution (use with caution)

Run Forcefully is available on jobs that may get stuck due to long-running processes or connection issues (Bounce Processing, Feedback Loop Processing, Maintenance Work, Segments Recount, RSS Dynamic Content Tags).

warning

Use Run Forcefully sparingly. If a job is locked, it usually means it's still running. Forcing a second execution can cause duplicate processing or data issues.

---

Cron Jobs

Email Campaigns

Starts sending scheduled broadcasts and processes active campaign queues.

Default	Description
1 Min	Checks for campaigns ready to send every minute

Volume recommendations:

Volume	Interval	Rationale
High (100k+ daily)	1 Min	Ensures campaigns start promptly and queues process continuously
Medium (10k-100k daily)	1-5 Min	Good balance of responsiveness and server load
Low (under 10k daily)	5-15 Min	Reduces server overhead when immediate starts aren't critical

---

Trigger Processing

Evaluates trigger conditions and executes delayed trigger actions. Instant contact-based triggers run in real-time and don't depend on this cron.

Default	Description
1 Min	Processes delayed triggers and segment-based triggers

Volume recommendations:

Volume	Interval	Rationale
Time-sensitive automations	1 Min	Minimizes delay for triggers like "30 minutes after signup"
Standard automations	5-15 Min	Acceptable delay for most marketing automation
Low priority	15-30 Min	When trigger timing isn't critical

tip

Instant contact triggers (contact added, field changed) with "Instantly" timing execute in real-time without waiting for this cron. Only delayed triggers and segment-based triggers are processed here.

---

Bounce Processing

Connects to bounce mailboxes and retrieves bounce notifications to update contact statuses.

Default	Description
2 Hour	Fetches and processes bounces from configured mailboxes

Volume recommendations:

Volume	Interval	Rationale
High volume sending	30 Min - 1 Hour	Faster bounce detection helps protect sender reputation
Standard	2 Hour	Good balance - bounces are processed same-day
Low volume	6-12 Hour	When rapid bounce detection isn't critical

info

Bounce processing involves connecting to external mailboxes (IMAP/POP3), which can be slow. More frequent processing means more connections but faster bounce handling.

---

Feedback Loop Processing

Processes feedback loop (FBL) reports - spam complaints from ISPs.

Default	Description
24 Hour	Processes spam complaint reports from configured FBL addresses

Volume recommendations:

Volume	Interval	Rationale
High volume ESP	2-6 Hour	Faster complaint detection to protect reputation
Standard	12-24 Hour	Daily processing is adequate for most senders

Spam complaints are serious reputation signals. Processing them more frequently helps you respond faster to deliverability issues.

---

Maintenance Work

Runs system cleanup and optimization tasks including clearing temporary files, optimizing tables, and general housekeeping.

Default	Description
24 Hour	Performs daily system maintenance

Recommendations:

Scenario	Interval	Rationale
High activity systems	12-24 Hour	More frequent cleanup for systems with heavy usage
Standard	24 Hour	Daily maintenance is sufficient for most installations

---

Segments Recount

Recalculates contact counts for dynamic segments by re-evaluating segment conditions.

Default	Description
24 Hour	Recounts contacts matching each segment's criteria

Recommendations:

Scenario	Interval	Rationale
Dynamic targeting needs	6-12 Hour	When segment counts need to reflect recent changes
Standard	24 Hour	Daily recount is sufficient for most use cases
Static segments only	24 Hour or longer	When segment membership rarely changes

note

Segment recounting can be resource-intensive on large databases. If you have millions of contacts with complex segment conditions, consider running this during off-peak hours.

---

Pending Stats

Processes pending statistics calculations and updates campaign metrics.

Default	Description
1 Min	Aggregates and updates statistics from raw tracking data

Recommendations:

Scenario	Interval	Rationale
Real-time dashboards	1 Min	Statistics update almost immediately
Standard	1-5 Min	Near real-time stats with lower overhead
Batch reporting	15-30 Min	When real-time stats aren't needed

---

Delete Exported Files

Removes exported files that have exceeded the retention period set in Application Settings.

Default	Description
2 Hour	Checks and deletes expired export files

Recommendations:

Scenario	Interval	Rationale
Standard	2 Hour	Files are cleaned up within hours of expiration
Disk space concerns	1 Hour	More frequent cleanup to free disk space
Minimal	6-12 Hour	When disk space isn't a concern

---

Click Tracking

Processes click tracking data when using cron-based tracking mode.

Default	Description
1 Min	Processes queued click events into statistics

Recommendations:

Scenario	Interval	Rationale
Cron tracking mode	1 Min	Clicks appear in stats within a minute
Real-time tracking mode	Can be longer	If using real-time driver, this is supplementary

---

Open Tracking

Processes open tracking data when using cron-based tracking mode.

Default	Description
1 Min	Processes queued open events into statistics

Recommendations:

Scenario	Interval	Rationale
Cron tracking mode	1 Min	Opens appear in stats within a minute
Real-time tracking mode	Can be longer	If using real-time driver, this is supplementary

---

Engagement Processing

Calculates and updates contact engagement scores based on opens, clicks, and other interactions.

Default	Description
1 Min	Updates engagement metrics for contacts

Recommendations:

Scenario	Interval	Rationale
Active engagement tracking	1 Min	Real-time engagement score updates
Standard	5-15 Min	Near real-time engagement data

---

Triggers Checkup

Monitors trigger health, retries failed trigger actions, and performs trigger maintenance.

Default	Description
24 Hour	Checks trigger status and retries failed actions

Recommendations:

Scenario	Interval	Rationale
Mission-critical triggers	6-12 Hour	Faster recovery from trigger failures
Standard	24 Hour	Daily checkup is sufficient for most setups

---

Suppression Processing

Processes suppression list updates and applies suppressions to contact databases.

Default	Description
15 Min	Syncs suppression lists and marks suppressed contacts

Recommendations:

Scenario	Interval	Rationale
Active suppression management	15 Min	Suppressions take effect within 15 minutes
Standard	15-30 Min	Good balance for most installations
Low volume	1 Hour	When suppression timing isn't critical

---

Queue Work

Processes Laravel's background job queue for tasks like notifications, imports, and other queued operations.

Default	Description
1 Min	Processes queued jobs

Recommendations:

Scenario	Interval	Rationale
Using Supervisor	Can be disabled	Supervisor handles queue processing continuously
Cron-based queue	1 Min	Jobs process within a minute of being queued
Low priority jobs	5-15 Min	When immediate processing isn't needed

Supervisor Alternative

For high-volume installations, using Supervisor to run queue workers continuously is more efficient than cron-based processing. When using Supervisor, this cron can serve as a fallback.

---

Stuck Campaigns

Detects campaigns that have stopped processing unexpectedly and attempts to restart them.

Default	Description
2 Hour	Checks for and restarts stuck campaigns

Recommendations:

Scenario	Interval	Rationale
High volume sending	1-2 Hour	Faster recovery from stuck campaigns
Standard	2 Hour	Campaigns are recovered within a few hours
Low volume	6-12 Hour	When quick recovery isn't critical

---

Limit Reset

Resets sending limits, trigger limits, and other quota counters on their billing cycle.

Default	Description
24 Hour	Checks and resets limits that have reached their reset date

Recommendations:

Scenario	Interval	Rationale
Standard	24 Hour	Limits reset once daily is appropriate
Strict limit enforcement	12 Hour	More frequent checks for limit resets

---

Evergreen Campaigns

Processes evergreen (recurring) campaigns - broadcasts that automatically repeat at scheduled intervals.

Default	Description
5 Min	Checks and queues evergreen campaigns ready to run

Recommendations:

Scenario	Interval	Rationale
Precise scheduling needed	1-5 Min	Evergreens start close to their scheduled time
Standard	5 Min	Good balance of precision and overhead
Flexible scheduling	15-30 Min	When exact start times aren't critical

---

RSS Dynamic Content Tags

Fetches and caches RSS feed content for use in dynamic email content.

Default	Description
1 Hour	Updates RSS feed cache for dynamic content tags

Recommendations:

Scenario	Interval	Rationale
Frequently updated feeds	30 Min - 1 Hour	Content stays relatively current
Standard	1 Hour	Hourly updates are sufficient for most feeds
Rarely updated feeds	2-6 Hour	When feed content doesn't change often

---

Server Cron Setup

To enable Mumara's scheduler, add this entry to your server's crontab:

* * * * * cd /path/to/mumara && php artisan schedule:run >> /dev/null 2>&1

This runs Laravel's scheduler every minute, which then executes tasks based on your configured intervals.

Accessing Crontab

crontab -e

Verifying Cron

Check if cron is running:

systemctl status cron

---

Volume-Based Configuration Profiles

High Volume (100k+ emails/day)

Job	Interval
Email Campaigns	1 Min
Trigger Processing	1 Min
Bounce Processing	1 Hour
Feedback Loop Processing	6 Hour
Pending Stats	1 Min
Click/Open Tracking	1 Min
Queue Work	1 Min (or use Supervisor)
Stuck Campaigns	1 Hour
Evergreen Campaigns	5 Min

Medium Volume (10k-100k emails/day)

Job	Interval
Email Campaigns	1-5 Min
Trigger Processing	5 Min
Bounce Processing	2 Hour
Feedback Loop Processing	12 Hour
Pending Stats	1-5 Min
Click/Open Tracking	1 Min
Queue Work	1-5 Min
Stuck Campaigns	2 Hour
Evergreen Campaigns	5 Min

Low Volume (under 10k emails/day)

Job	Interval
Email Campaigns	5-15 Min
Trigger Processing	15 Min
Bounce Processing	6 Hour
Feedback Loop Processing	24 Hour
Pending Stats	5-15 Min
Click/Open Tracking	5 Min
Queue Work	5 Min
Stuck Campaigns	6 Hour
Evergreen Campaigns	15 Min

---

Best Practices

Interval Selection

• Start with defaults - The suggested values work well for most installations
• Monitor server load - Watch CPU/memory during peak cron activity
• Consider volume - Higher email volume justifies more frequent processing
• Avoid overlap - Ensure resource-intensive tasks complete before next run

Performance Tips

• Stagger intensive jobs - Don't run Maintenance, Segments Recount, and Bounce Processing at the same time
• Use Supervisor for queues - More efficient than cron-based queue processing for high volume
• Monitor logs - Check cron execution in Tools → Cron Status
• Run during off-peak - Schedule intensive jobs (Maintenance, Segments Recount) during low-traffic periods

---

Troubleshooting

Cron Jobs Not Running

Possible causes:

• Server cron not configured
• Laravel scheduler not set up
• Permission issues

Solutions:

• Verify server crontab entry exists
• Check Laravel log for scheduler errors
• Ensure web user can execute artisan commands

Tasks Running Too Slowly

Possible causes:

• Too many tasks at same interval
• Server resource constraints
• Large data volumes

Solutions:

• Stagger task intervals
• Increase server resources
• Optimize database indexes
• Reduce data retention periods

Jobs Appear Stuck

Possible causes:

• Previous run still executing
• Database locks
• External service timeouts

Solutions:

• Check if job is actually still running
• Use Run Forcefully to bypass locks (with caution)
• Check database for lock issues
• Review logs for timeout errors

---

Next Steps

• Application Settings - Configure application options
• Tools → Cron Status - View cron job execution status