Use case
Automating Daily Digest Emails and Scheduled Reports
Reduce notification fatigue and keep stakeholders informed — without building a scheduling system from scratch.
Use case
Reduce notification fatigue and keep stakeholders informed — without building a scheduling system from scratch.
Every SaaS product eventually hits the same inflection point: users start drowning in real-time notifications. An activity feed that sends an email for every comment, every status change, every mention becomes noise — and noise gets ignored.
Daily digests solve this by compressing many events into a single, well-structured message. Instead of seventeen separate emails about project activity, your user gets one morning summary they can scan in thirty seconds. The result is measurable: teams that switch from real-time notifications to daily digests typically see 2-3x higher email open rates and significantly lower unsubscribe rates.
Beyond user-facing notifications, scheduled reports serve a different audience. Executives want a daily revenue snapshot. Engineering leads want a deployment summary. Customer success wants a churn risk report. These are all variations of the same technical problem: run a query, format the results, deliver them on a schedule.
Before choosing a technical approach, it helps to understand what you're building. Most digests fall into one of these categories:
The implementation complexity varies. Activity summaries require event collection throughout the day. Metric reports just need a well-indexed database query. Content roundups need a ranking algorithm. But they all share the same core requirement: something needs to trigger the compilation and send at a predictable time.
When your digest arrives matters more than most teams realize.
Morning vs. evening. Activity digests usually perform best delivered in the morning — "here's what happened while you were away." Metric reports work well as end-of-day summaries. Test both and measure open rates.
Timezone handling. If your users span multiple timezones, a single 0 9 * * * cron expression won't cut it. "9 AM" means something different in London and Tokyo. There are two common approaches: group users into timezone buckets and run the job multiple times (e.g., every hour, processing users whose local time is 9 AM), or let users pick their preferred delivery time and schedule per-user.
Weekdays only. For B2B products, Monday-through-Friday digests often outperform daily ones. Nobody reads their project summary on Saturday. A cron expression like 0 9 * * 1-5 handles this natively.
Empty digests. If there's nothing to report, don't send anything. An empty digest teaches users to ignore your emails. Check for content before sending, and skip silently when there's nothing new.
There's no single right way to trigger a daily digest. The best approach depends on your infrastructure, team size, and how critical the delivery timing is. Here are the most common options.
The classic. You SSH into your server, run crontab -e, and add a line that calls your script every morning.
# /etc/crontab — run digest at 9 AM UTC every weekday
0 9 * * 1-5 www-data /usr/bin/php /var/www/app/scripts/send-digest.php >> /var/log/digest.log 2>&1This is simple, battle-tested, and requires zero external dependencies. It's also fragile. If the server goes down, nobody gets their digest and nobody gets notified. The cron daemon doesn't retry failed jobs. Logs get buried in files nobody checks. And when you move to a multi-server setup or containers, the crontab doesn't come with you.
Good for: solo projects, internal tools, early-stage prototypes.
Most web frameworks include a built-in scheduler that wraps system cron with application-level conveniences. Laravel has Task Scheduling, Spring has @Scheduled, Django has Celery Beat, Rails has Whenever.
# Laravel — app/Console/Kernel.php (or routes/console.php in Laravel 11+)
Schedule::command('digest:send')
->weekdays()
->at('09:00')
->withoutOverlapping()
->onFailure(fn () => Log::error('Digest failed'));
Framework schedulers give you overlap prevention, failure callbacks, and timezone support out of the box. The trade-off is that you still need a long-running process (or a cron entry that runs schedule:run every minute) on a server you control. You also tie your scheduling logic to your application deployment — if the deploy breaks, the scheduler breaks too.
Good for: teams already invested in a framework, moderate reliability requirements.
AWS EventBridge Scheduler, Google Cloud Scheduler, and Azure Logic Apps can all trigger HTTP endpoints or Lambda functions on a cron schedule. They're highly available, regionally distributed, and backed by cloud SLAs.
The downside is complexity and cost at low scale. Setting up EventBridge to call a Lambda that calls your API requires IAM roles, VPC configuration, and CloudFormation or Terraform templates. Google Cloud Scheduler is simpler — it can hit an HTTP endpoint directly — but you're still managing cloud-specific configuration outside your application.
Good for: teams already deep in AWS/GCP, enterprise compliance requirements.
GitHub Actions, GitLab CI, and similar platforms support scheduled workflows via cron expressions. You can define a workflow that runs every morning and calls your digest endpoint.
This is free (within usage limits) and requires no infrastructure. However, GitHub explicitly warns that scheduled workflows may be delayed or skipped during high-load periods. Timing accuracy is not guaranteed, and there's no built-in retry or alerting. It works in a pinch, but it's not what CI/CD was designed for.
Good for: non-critical digests, side projects, workflows already in CI/CD.
Services like Recuro, EasyCron, and cron-job.org take the simplest possible approach: you give them a URL and a cron expression, and they send an HTTP request on schedule. Your application exposes a /compile-digest endpoint, and the service calls it at the configured time.
# Recuro API — schedule a weekday digest at 9 AM UTC
curl -X POST https://app.recurohq.com/api/crons \
-H "Authorization: Bearer {{token}}" \
-H "Content-Type: application/json" \
-d '{
"name": "Daily activity digest",
"url": "https://yourapp.com/api/internal/compile-digest",
"method": "POST",
"cron_expression": "0 9 * * 1-5",
"headers": {
"X-Internal-Key": "{{your-secret}}"
}
}'This decouples scheduling from your application entirely. Your app doesn't need a scheduler process, a cron daemon, or a cloud provider integration. The HTTP cron service handles reliability, retries, and alerting. If your endpoint returns a 500, services like Recuro will retry automatically and notify you when something breaks.
Good for: teams that want scheduling without managing scheduling infrastructure.
Regardless of how you trigger the digest, the compilation and delivery architecture matters.
Precomputed digests aggregate events throughout the day into a staging table. When the digest job runs, it just formats and sends what's already been collected. This is fast at send time but requires write-time overhead.
On-demand digests query raw event data when the job fires. Simpler to implement, but the query can be slow if you're scanning millions of events across thousands of users. For most applications under 10,000 users, on-demand works fine. Beyond that, precomputation is worth the complexity.
Never send thousands of emails synchronously inside a single HTTP request or cron job. Your digest trigger should compile the content and push individual sends onto a job queue (SQS, Redis, RabbitMQ, your framework's queue). This prevents timeouts, enables parallel sending, and isolates failures — one bounced email doesn't block the rest.
# Pseudo-code for a digest endpoint
def compile_digest():
users = get_users_due_for_digest(timezone=request.timezone_bucket)
for user in users:
events = get_events_since_last_digest(user)
if events:
queue.push(SendDigestEmail, user_id=user.id, events=events)
return { "queued": len(users) }If you support multiple timezones, the simplest pattern is to run your trigger every hour and pass the current UTC hour as a parameter. Your endpoint then processes only users whose preferred delivery hour matches. With 24 runs per day, each batch is roughly 1/24th of your user base.
A digest that silently fails is worse than no digest at all — because you think it's working.
Track execution. Log every digest run: how many users were processed, how many emails were queued, how long it took. A sudden drop in "users processed" often signals a bug before users report it.
Alert on failure. If your digest endpoint returns an error or doesn't run at all, you need to know immediately. Framework schedulers can hook into your error tracking (Sentry, Bugsnag). HTTP cron services like Recuro provide built-in failure alerts — if your endpoint returns a non-2xx response, you get notified after a configurable threshold.
Monitor delivery metrics. Open rates, bounce rates, and complaint rates are your feedback loop. A spike in bounces might mean your email provider is throttling you. A drop in opens might mean your digest is landing in spam.
Dead man's switch. For truly critical digests, set up a heartbeat check. Your digest endpoint pings a monitoring service (Healthchecks.io, Better Uptime, or similar) on successful completion. If the ping doesn't arrive, you get alerted. This catches the failure mode where the scheduler itself stops running — something none of the other monitoring will catch.
There's no universal answer. A solo developer with a side project should use system cron and move on. A team running a Laravel or Rails app should probably use the framework's built-in scheduler until they outgrow it. If you're already in AWS and have Terraform set up, Cloud Scheduler is a natural fit.
If you want to avoid managing scheduling infrastructure entirely — no crontabs, no scheduler processes, no cloud-specific configuration — an HTTP cron service is the simplest path. Point it at your endpoint and let it handle the timing, retries, and alerting while you focus on making the digest content actually useful.
Whatever you choose, the important thing is that your digest runs reliably, fails loudly, and respects your users' attention.
Recuro handles scheduling, retries, alerts, and execution logs. 1,000 free requests to start.
No credit card required