Expert CLI: jobs and email reports

Identify the installation and execution account

The examples use /var/www/html/obelisk and /usr/bin/php. Replace these with the actual installation path and PHP CLI executable. Connect to the PBX by SSH with permission to use sudo; execute one command at a time. Workers and utilities that load application settings normally run as asterisk. Commands explicitly marked sudo without -u require administrative OS privileges.

Keep the original extracted installer and its saved state. The installer directory and application directory are different. Before a repair, identify the fault and preserve an appropriate backup. Do not put passwords, API keys or SQL credentials in command arguments, screenshots or shared logs.

1. Enter the application directory

   The relative PHP paths below start here. This command only changes the current shell directory.

   Command

   cd /var/www/html/obelisk

Read the installed schedule

A standard installation writes /etc/cron.d/obelisk with six job types, all running as asterisk. There are seven command lines because audio has two staggered launches. The table shows installation defaults; existing custom times and options are preserved by the official pause/resume commands.

Linux times follow the server’s cron time zone. SQL events use the database event scheduler and their own recorded time zone. The report time zone selects the report period; changing it does not reschedule cron. View the installed file and the Database events panel before interpreting a late run.

1. Inspect the actual Linux schedule

   Read-only command. Lines beginning with # are inactive. Keep this file in /etc/cron.d: do not import it with crontab.

   Command

   sudo cat /etc/cron.d/obelisk

Pause and resume scheduled processing

Run these commands from the original installer directory, after installation has completed. For a custom installation append the same --path and --php options used during installation. The tool uses the saved installation state and may require SQL administrative access. If the kit or state is missing, ask Obelisk support; do not rerun a fresh installation over the live application.

1. Pause future invocations

   Disables Obelisk Linux schedules and its min_queue/min_out SQL events. Existing processes are not interrupted. Wait for work already running to finish before performing maintenance. Read the final messages: if SQL access fails, Linux schedules may already be disabled while SQL events remain unverified.

   Command

   sudo bash install.sh --disable-jobs

2. Resume after verification

   Re-enables Obelisk schedules and requests activation of its SQL events. It preserves existing custom times/options and leaves recording-deletion switches separate. If enabling the global SQL scheduler would also start other applications’ events, evaluate the explicit prompt with the SQL administrator. Resolve any warning and repeat the same command; do not treat Linux enablement alone as confirmation of SQL processing.

   Command

   sudo bash install.sh --activate-jobs

3. Verify both layers

   In Administration review the installed job schedule, recent observations and SQL processing state. Confirm that a new eligible run occurs after resuming. Disabling these schedules does not shut down FreePBX and is not a blanket prohibition on an expert deliberately launching a worker manually.

Choose the correct report and period

Before rerunning a report, confirm its intended dates, the PBX/report time zone, available recording analyses, Gemini configuration, report language, SMTP sender and REPORT_EMAIL_TO recipients in System and utilities. A report is generated from saved recording analyses; it is not an automatic analysis of every unprocessed audio file.

The report time zone defines calendar boundaries; it does not rewrite cron times. The installed scheduler follows the server schedule and its configured time zone. Inspect both and use the preview output as the reference for the selected dates.

Check eligibility without AI or email

Use the direct entry point when you want progress in the terminal as well as the configured log. These scripts pass through the same official runner. Choose the weekly or monthly command for the report being investigated.

1. Preview the weekly report

   Read period, time zone, summaries, minimum_summaries, coverage and eligible. Unknown call dates and incomplete analyses can reduce the usable sample.

   Command

   sudo -u asterisk /usr/bin/php cron_weekly_trends.php --dry-run

2. Preview the monthly report

   Read valid_calls, minimum_calls and eligible. The monthly minimum is 10 usable calls. The output identifies the actual period; do not infer it from the command date alone.

   Command

   sudo -u asterisk /usr/bin/php cron_monthly_report.php --dry-run

Run once, then verify delivery

After resolving the cause and checking that the report was not already delivered, choose one of the following commands. A normal run may consume Gemini quota and sends to the current real recipients. A manual invocation does not change the installed cron schedule.

1. Generate the weekly report

   Wait for completion and read the final AI/SMTP result. A configuration skip, insufficient-data message or already-running lock is not an email delivery.

   Command

   sudo -u asterisk /usr/bin/php cron_weekly_trends.php

2. Generate the monthly report

   Use this for the previous calendar month. Do not add --test merely because you are troubleshooting: that option changes the reporting window and still sends email.

   Command

   sudo -u asterisk /usr/bin/php cron_monthly_report.php

3. Verify the final outcome

   Check the command exit status immediately, then the log, Administration job observation and mailbox. Exit 0 alone can also mean an intentional skip. SMTP success means server acceptance, not proof that the message reached the inbox. Inspect spam/quarantine or mail-server traces when needed.

   Command

   echo $?

Find logs and separate worker outcomes

The runner resolves log locations from the installation settings; do not assume a fixed logs directory. The --log-path form returns the selected job’s path without launching that worker. Replace weekly with monthly, audio, logger, cleaner or retention as needed. Read the returned file with your normal authorized log viewer; redact recipients and infrastructure details before sharing it.

1. Find the weekly log

   The output is a path, not a report-generation result.

   Command

   sudo -u asterisk /usr/bin/php cron_run.php --log-path weekly