Source: https://cli.nylas.com/guides/automate-email-reports-terminal # Automate Email Reports from Terminal You check the same inboxes every morning, count unread threads, scan for sender patterns, and type the same summary into Slack. That's 15 minutes a day you won't get back. This guide builds shell pipelines that extract email data as JSON, shape it with jq, and deliver formatted reports on a schedule — no browser, no GUI, and no Python scripts. Written by [Prem Keshari](https://cli.nylas.com/authors/prem-keshari) Senior SRE Updated May 22, 2026 > **TL;DR:** Pipe `nylas email list --json` through `jq` to extract sender counts, unread totals, and thread volumes. Wrap the pipeline in a bash script, schedule it with cron, and deliver results via `nylas email send`. ## Why automate email reports from the terminal? Manual inbox audits waste time that compounds. A 10-minute daily check costs 43 hours per year, per [Harvard Business Review's 2019 email productivity research](https://hbr.org/2019/01/how-to-spend-way-less-time-on-email-every-day). Multiply that across 3-5 monitored mailboxes and you're losing a full work week annually on a task a shell script handles in under 2 seconds. Terminal-based reporting solves three recurring problems. First, it eliminates the context switch between email clients and wherever you report status. Second, it produces consistent output: same fields, same format, same time every day. Third, it integrates with existing tooling. A script that outputs JSON can feed dashboards, Slack webhooks, PagerDuty, or another CLI command. The Nylas CLI's `--json` flag turns email queries into structured data. Combined with `jq` for transformation and `cron` for scheduling, you get a reporting pipeline that runs unattended across Gmail, Outlook, Yahoo, iCloud, and IMAP accounts. ## How do you extract email data with JSON output? The [`nylas email list`](https://cli.nylas.com/docs/commands/email-list) command returns messages as a JSON array when you pass `--json`. Each object includes fields like `from`, `subject`, `date`, `unread`, and `folder`. A single query returns up to 50 messages by default, or more with `--limit`. Here's a quick pipeline that lists unread messages and extracts the sender and subject with `jq`. The `-r` flag outputs raw strings without JSON quotes, which is cleaner for reports. Terminal File: `Terminal` ```bash # List unread messages as JSON, extract sender + subject nylas email list --unread --json | \ jq -r '.[] | "\(.from[0].email) \(.subject)"' # Count unread messages per folder nylas email list --unread --all --json | \ jq -r 'group_by(.folders[0]) | .[] | "\(.[0].folders[0]): \(length)"' # Top 5 senders by message count nylas email list --limit 100 --json | \ jq -r '[.[] | .from[0].email] | group_by(.) | map({sender: .[0], count: length}) | sort_by(-.count) | .[:5][] | "\(.count) \(.sender)"' ``` The `--json` flag is the foundation of every pipeline in this guide. Without it, you'd be parsing formatted terminal output with `awk` and `sed`, which breaks whenever the display format changes. JSON output is stable across CLI versions. ## How do you build a daily inbox summary? A daily summary answers three questions in under 10 lines: how many unread messages, who's sending the most, and what are the newest threads. The script below collects these metrics, formats a plain-text report, and prints it to stdout. You can redirect stdout to a file, pipe it to `nylas email send`, or post it to Slack. This script processes roughly 100 messages in 1.5 seconds on a typical connection. The API call is the bottleneck, not `jq` — JSON parsing adds under 50 milliseconds for 100 records. daily-inbox-summary.sh File: `daily-inbox-summary.sh` ```bash #!/bin/bash # Daily inbox summary — unread count, top senders, newest threads # Usage: ./daily-inbox-summary.sh # Cron: 0 8 * * 1-5 /opt/scripts/daily-inbox-summary.sh set -euo pipefail REPORT_DATE=$(date +%Y-%m-%d) TMPFILE=$(mktemp) # Fetch unread messages as JSON nylas email list --unread --limit 100 --json > "$TMPFILE" 2>/dev/null UNREAD_COUNT=$(jq 'length' "$TMPFILE") TOP_SENDERS=$(jq -r ' [.[] | .from[0].email] | group_by(.) | map({sender: .[0], count: length}) | sort_by(-.count) | .[:5][] | " \(.count) \(.sender)" ' "$TMPFILE") # Fetch newest threads NEWEST=$(nylas email threads list --limit 5 --json 2>/dev/null | \ jq -r '.[] | " \(.last_message_timestamp | strftime("%H:%M")) \(.subject[:60])"') # Build the report REPORT="INBOX SUMMARY — $REPORT_DATE ================================ Unread messages: $UNREAD_COUNT Top senders: $TOP_SENDERS Newest threads: $NEWEST --- Generated at $(date -u +%H:%M:%S) UTC" echo "$REPORT" rm -f "$TMPFILE" ``` Run it manually first to verify the output. The `set -euo pipefail` line ensures the script exits on any error instead of silently producing a partial report. Once you're satisfied, wire it into cron (covered below). ## How do you create a weekly email report? A weekly report aggregates 7 days of email activity into a single digest. The [`nylas email search`](https://cli.nylas.com/docs/commands/email-search) command accepts `--after` and `--before` flags for date-range filtering. Combined with `jq`, you can compute metrics like total volume, unique sender count, and attachment frequency across the full week. Enterprise inboxes receive an average of 120 messages per day, according to [The Radicati Group's 2024 Email Statistics Report](https://www.radicati.com/wp/wp-content/uploads/2024/01/Email-Statistics-Report-2024-2028-Executive-Summary.pdf). A weekly report covering 840 messages typically runs in 4-6 seconds because the CLI paginates API calls internally. weekly-email-report.sh File: `weekly-email-report.sh` ```bash #!/bin/bash # Weekly email report — volume, senders, attachments # Usage: ./weekly-email-report.sh # Cron: 0 9 * * 1 /opt/scripts/weekly-email-report.sh set -euo pipefail WEEK_START=$(date -d "7 days ago" +%Y-%m-%d 2>/dev/null || date -v-7d +%Y-%m-%d) WEEK_END=$(date +%Y-%m-%d) TMPFILE=$(mktemp) # Search for all messages in the past 7 days nylas email search "" --after "$WEEK_START" --before "$WEEK_END" --json > "$TMPFILE" 2>/dev/null TOTAL=$(jq 'length' "$TMPFILE") UNIQUE_SENDERS=$(jq '[.[] | .from[0].email] | unique | length' "$TMPFILE") WITH_ATTACHMENTS=$(jq '[.[] | select(.has_attachments == true)] | length' "$TMPFILE") UNREAD_LEFT=$(jq '[.[] | select(.unread == true)] | length' "$TMPFILE") # Top 10 senders for the week SENDER_TABLE=$(jq -r ' [.[] | .from[0].email] | group_by(.) | map({sender: .[0], count: length}) | sort_by(-.count) | .[:10][] | " \(.count | tostring | (" " + .)[-4:]) \(.sender)" ' "$TMPFILE") # Day-by-day breakdown DAILY_COUNTS=$(jq -r ' group_by(.date[:10]) | map({day: .[0].date[:10], count: length}) | sort_by(.day)[] | " \(.day) \(.count) messages" ' "$TMPFILE") REPORT="WEEKLY EMAIL REPORT $WEEK_START to $WEEK_END ============================ Total messages: $TOTAL Unique senders: $UNIQUE_SENDERS With attachments: $WITH_ATTACHMENTS Still unread: $UNREAD_LEFT Top senders: $SENDER_TABLE Daily volume: $DAILY_COUNTS --- Generated at $(date -u +%Y-%m-%dT%H:%M:%SZ)" echo "$REPORT" rm -f "$TMPFILE" ``` The date command differs between Linux (`date -d`) and macOS (`date -v`). The script tries the GNU syntax first and falls back to BSD. If you deploy on only one platform, remove the fallback to keep the script cleaner. ## How do you schedule reports with cron? Cron is the standard Unix scheduler, installed on every Linux and macOS system since the 1970s. A cron expression has 5 fields: minute, hour, day-of-month, month, and day-of-week. Validate expressions with [crontab.guru](https://crontab.guru/) before deploying. The daily summary runs at 8 AM on weekdays with `0 8 * * 1-5`. The weekly report runs Mondays at 9 AM with `0 9 * * 1`. Two things break cron email scripts most often: missing PATH and missing HOME. Cron runs with a minimal environment that doesn't source your shell profile. Set both at the top of your crontab. The [cron email guide](https://cli.nylas.com/guides/cron-job-email-without-postfix) covers debugging in detail. crontab -e File: `crontab -e` ```bash # Environment for all cron jobs SHELL=/bin/bash HOME=/home/deploy PATH=/home/linuxbrew/.linuxbrew/bin:/usr/local/bin:/usr/bin:/bin # Daily inbox summary at 8:00 AM, weekdays only 0 8 * * 1-5 /opt/scripts/daily-inbox-summary.sh 2>> /var/log/email-reports.log # Weekly digest every Monday at 9:00 AM 0 9 * * 1 /opt/scripts/weekly-email-report.sh 2>> /var/log/email-reports.log # Hourly unread check (alert-only, see next section) 0 * * * * /opt/scripts/unread-alert.sh 2>> /var/log/email-reports.log ``` Use full paths to your scripts. Cron's working directory is unpredictable, and relative paths are the source of roughly 30% of cron debugging sessions according to Stack Overflow's developer survey data. Redirect stderr to a log file so failures don't vanish silently. ## How do you deliver reports by email? Pipe the report script's output directly to [`nylas email send`](https://cli.nylas.com/docs/commands/email-send). The `--yes` flag skips the interactive confirmation prompt, which is required for unattended execution. The `--body` flag accepts the report content, and command substitution `$(...)` captures the script's stdout. Delivery completes in under 3 seconds for plain-text reports. HTML reports with inline CSS add about 200 milliseconds. The CLI auto-detects HTML content and sets the correct MIME type. crontab -e File: `crontab -e` ```bash # Deliver daily summary by email at 8 AM 0 8 * * 1-5 nylas email send \ --to team@company.com \ --subject "Inbox Summary — $(date +\%Y-\%m-\%d)" \ --body "$(/opt/scripts/daily-inbox-summary.sh)" \ --yes 2>> /var/log/email-reports.log # Deliver weekly digest every Monday at 9 AM 0 9 * * 1 nylas email send \ --to manager@company.com \ --subject "Weekly Email Report — $(date +\%Y-\%m-\%d)" \ --body "$(/opt/scripts/weekly-email-report.sh)" \ --yes 2>> /var/log/email-reports.log ``` For self-notification, set `--to` to your own address. That way you get the report in the same inbox you're monitoring. Some teams send to a shared Slack channel instead by piping the output to `curl` with a Slack webhook URL, but email delivery via the CLI is more reliable because it doesn't depend on a third-party webhook endpoint staying up. ## How do you set up alert-based reports? Alert-based reports fire only when a condition is met, which prevents inbox fatigue. Instead of getting 24 hourly “all clear” messages, you get one email when unread messages exceed a threshold. The script below checks unread count every hour and sends an alert only if the count exceeds 50. Threshold-based alerting reduces notification volume by 85-95% compared to fixed-interval reporting, based on typical inbox patterns where only 2-3 hours per day exceed the threshold. That keeps the alert signal high. /opt/scripts/unread-alert.sh File: `/opt/scripts/unread-alert.sh` ```bash #!/bin/bash # Unread threshold alert — sends email only when count exceeds limit # Cron: 0 * * * * /opt/scripts/unread-alert.sh set -euo pipefail THRESHOLD=50 RECIPIENT="ops@company.com" LOGFILE="/var/log/unread-alerts.log" # Count unread messages UNREAD=$(nylas email list --unread --all --json 2>/dev/null | jq 'length') if [ "$UNREAD" -gt "$THRESHOLD" ]; then # Get top senders contributing to the backlog TOP=$(nylas email list --unread --limit 50 --json 2>/dev/null | \ jq -r '[.[] | .from[0].email] | group_by(.) | map({s: .[0], c: length}) | sort_by(-.c) | .[:3][] | " \(.c) from \(.s)"') nylas email send \ --to "$RECIPIENT" \ --subject "ALERT: $UNREAD unread messages (threshold: $THRESHOLD)" \ --body "Unread message count has reached $UNREAD, exceeding the $THRESHOLD threshold. Top senders: $TOP Check your inbox or adjust filters. Timestamp: $(date -u +%Y-%m-%dT%H:%M:%SZ)" \ --yes \ --json >> "$LOGFILE" 2>&1 fi ``` You can extend this pattern to other conditions. For example, alert when starred messages pile up past 20, or when a specific sender's messages go unread for more than a day. The `--from` and `--starred` flags on `nylas email list` make these filters straightforward. Terminal File: `Terminal` ```bash # Alert when starred messages exceed 20 STARRED=$(nylas email list --starred --json 2>/dev/null | jq 'length') [ "$STARRED" -gt 20 ] && nylas email send \ --to you@company.com \ --subject "Starred backlog: $STARRED items" \ --body "You have $STARRED starred messages waiting for action." \ --yes # Alert when a VIP sender has unread messages VIP_UNREAD=$(nylas email list --unread --from ceo@company.com --json 2>/dev/null | jq 'length') [ "$VIP_UNREAD" -gt 0 ] && nylas email send \ --to you@company.com \ --subject "$VIP_UNREAD unread from CEO" \ --body "You have $VIP_UNREAD unread messages from ceo@company.com." \ --yes ``` ## Next steps You now have three reporting patterns: daily summaries, weekly digests, and threshold alerts. Each one runs from a shell script, scheduled by cron, and delivered via the CLI. Start with the daily summary, run it manually for a week, then add cron when you trust the output. - [Send email from terminal](https://cli.nylas.com/guides/send-email-from-terminal) — all send options including CC, BCC, HTML body, attachments, and scheduling - [Cron job email without Postfix](https://cli.nylas.com/guides/cron-job-email-without-postfix) — deeper coverage of cron debugging, PATH issues, and delivery verification - [GitHub Actions email notifications](https://cli.nylas.com/guides/github-actions-email-notifications) — apply the same pattern to CI/CD pipelines with encrypted secrets - [`nylas email list` command reference](https://cli.nylas.com/docs/commands/email-list) — all flags for filtering, sorting, and JSON output - [Full command reference](https://cli.nylas.com/docs/commands) — all 72+ CLI commands for email, calendar, contacts, and authentication - [Getting started](https://cli.nylas.com/guides/getting-started) — install methods for macOS, Linux, Windows, and Go