Navigation
10.25. Investigate Background Jobs and Email Delivery
Use Job Monitoring and outbound Email Logs to investigate failures, inspect details, and clear tenant job history with the required permission.
When background work or a notification fails, dispatch needs evidence before repeating the operation. System Monitoring brings job history and outbound email activity into the MSP interface. For a missing Harbor Clinic notification, these views help distinguish a failed send from a background task that needs further investigation.
Before you begin
Use an authenticated MSP account. Email Logs rejects client-portal users, and clearing job history requires an MSP user with job:delete permission. Ordinary monitoring and outbound log viewing do not require an AI add-on.
Collect the approximate time, client or recipient, and ticket number where relevant. This gives you a useful starting point without assuming that a job failure and an email failure share the same cause.
Inspect background jobs
- Expand System Monitoring in the sidebar and select Job Monitoring.
- Review the summary cards for Total Jobs, Completed, Failed, Pending, Queued, and Running, including runner-specific counts where displayed.
- In Recent Jobs, inspect Job Name, Runner, Status, Duration, Started, and Ended. Use the table's sorting and pagination to examine the relevant rows.
- Select a job row to open Job Details. Review Job Progress, Job Metrics, and Job History, including any available step information, processed times, or retries.
- Record the job identifier and relevant error or step information before clearing historical entries or escalating the issue.
| Status or summary | What it tells you |
|---|---|
| Pending / Queued | Work is waiting rather than recorded as finished. |
| Processing / Running | The job is in progress; an end time may not yet be available. |
| Completed | The job has recorded completion. |
| Failed | Inspect the job details to understand the recorded failure. |
The expected result is a specific job record and its execution history. A summary count alone does not identify which client operation failed. Use the row details to decide what to investigate in the feature that scheduled the job.
Clear tenant job history
- Select Clear History. If it is unavailable, ask an administrator to check job:delete permission.
- Choose Finished only to remove completed and failed history while retaining pending, queued, and running jobs, or All statuses to include every status.
- Optionally enable Only delete jobs older than a set age and enter Age in days as a whole number of at least one. The age cutoff uses when the job was created.
- Review the warning and select Clear History, or Cancel to leave history intact.
This permanently removes matching job history for your tenant. It does not stop or cancel jobs that are still running. Status scope and age work together, so an age-restricted Finished only cleanup removes only finished jobs older than that cutoff.
Investigate outbound email
- Open System Monitoring > Email Logs and review Total sent, Failed rate, and Today.
- Set Start date, End date, and Status—All, Sent, or Failed. Narrow further using Recipient or Ticket.
- Select Refresh when checking new activity. The table shows Time, Ticket, Recipient, Subject, and Status.
- Open a row to inspect Email Log Details: Sent at, Status, Provider, Message ID, To, From, Error, and Metadata, when available.
Use the error and provider details to investigate an outbound failure. A Sent entry records the application's sending outcome; it is not proof that a person read the message. If a sent notification is missing, use its recipient, time, and message ID when checking the receiving mailbox.
Trace an inbound problem separately
Email Logs is an outbound activity view. If an incoming Northstar Accounting message never became a ticket or comment, inspect the inbound provider's status, defaults, and processing diagnostics under Email > Inbound Email. Then return to Email Logs to check any expected outgoing acknowledgement or reply.
An empty outbound search does not establish that the inbound message was never received. Check the date range, recipient, ticket association, and whether the action was expected to send a notification before drawing that conclusion.