/monitoring-tasks

name: "N-central Monitoring & Tasks"
description: >
  N-central monitoring and automation: active-issue triage per customer or
  site, job statuses, the scheduled task -> status -> per-device details
  drill-down, and the safety rules for direct-support task execution.
when_to_use: >-
  When triaging N-central active issues, checking job statuses, drilling into scheduled-task
  results, or executing a direct support task on a device. Use when: ncentral active issues,
  ncentral alerts, ncentral job status, ncentral scheduled task, ncentral task status, ncentral
  direct task, ncentral run script, or ncentral automation.

N-central Monitoring & Tasks

Two related surfaces: **monitoring** (what N-central currently thinks is wrong — active issues and job statuses) and **tasks** (automation that has run or will run — scheduled tasks and direct support tasks). Triage flows from the first into the second.

Anti-triggers

• **Running a task on an endpoint managed elsewhere** —

`ncentral_create_direct_task` executes only on N-central-managed devices. The same request against another fleet is `immybot-script-execution`, `superops-runbooks`, `atera-agents`, `syncro-assets`, `connectwise-automate-scripts`, or `datto-rmm-jobs`.

• **ImmyBot maintenance sessions** — an N-central maintenance *window*

suppresses alerting for a period and executes nothing. The reconciliation run that shares the name is `immybot-maintenance-sessions`.

• **Turning an active issue into customer-visible work** — active issues

are not tickets; the service desk of record is `connectwise-psa-tickets`, `autotask-tickets`, `halopsa-tickets`, or the PSA the MSP actually uses.

• **Per-device monitor state** — the drill-down from an active issue is

`ncentral-devices`.

Active Issues

| Tool | Use For | |------|---------| | `ncentral_list_active_issues` | Current issues for one customer or site | | `ncentral_list_job_statuses` | Backup/AV/patch job outcomes for an org unit |

The critical constraint: **active issues are listed per customer or site org unit only** — there is no SO-level firehose. A cross-client sweep is a loop:

1. `ncentral_list_customers` — enumerate clients. 2. `ncentral_list_active_issues` per customer `orgUnitId`. 3. Aggregate, then group by severity and by what actually broke (notification trigger / service), not just by device.

Issue records carry the device, the service/monitor that tripped, severity, and how long it has been active. Long-standing issues (days old) are usually known noise or accepted risk; a burst of fresh issues across one customer usually shares one root cause (site down, DNS, a bad patch). Group before you rank.

`ncentral_list_job_statuses` covers job-shaped work (backups, AV scans, patch runs) with per-job outcomes — the place to answer "did last night's backups run?" per customer.

Scheduled Tasks: The Drill-Down

Task inspection is a three-level descent:

ncentral_list_device_tasks / ncentral_get_task     — what tasks exist / one task's definition
        └── ncentral_get_task_status               — aggregate outcome (completed / failed counts)
                └── ncentral_get_task_status_details — per-device results, output, return codes

Start at the top. `ncentral_get_task_status` tells you *whether* something failed; `ncentral_get_task_status_details` tells you *where and why* — per-target status and captured output. Only pull details when the aggregate shows failures or the user asks for output; details payloads are large on wide-target tasks.

Direct Support Tasks — HIGH IMPACT

`ncentral_create_direct_task` executes a task (script, command, quick fix) **immediately on a live device**. It is the one tool in this plugin that changes machine state. Non-negotiable rules:

1. **Always confirm first.** State the device (name + ID), the customer, the task/script, and any parameters — and get an explicit yes before the call. Never chain it silently at the end of a triage. 2. **One device per task.** Target a single device. For fleet-wide remediation, propose a scheduled task through the UI instead of looping direct tasks. 3. **It runs immediately.** There is no scheduling, no dry run, and no cancel once dispatched. Whatever the script does, it does now, as SYSTEM/root on a production endpoint. 4. **Follow up.** After dispatch, poll `ncentral_get_task_status` (and details on failure) and report the actual outcome — "task created" is not "task succeeded".

Best Practices

• Sweep active issues before touching tasks — the issue list tells you

whether automation is the right response at all.

• Correlate issues with maintenance windows

(`ncentral_list_maintenance_windows`) before escalating: a "down" server inside its patch window is expected.

• Note that active issues and scheduled tasks sit on preview-stage

endpoints in some N-central releases — if a tool 404s, check `https://<server>/api-explorer` (see api-patterns).

• Report counts with their scope: "14 active issues (ACME, orgUnitId 123)"

so results are reproducible.

Related Skills

• [api-patterns](../api-patterns/SKILL.md) - preview endpoints, pagination, rate limits
• [devices](../devices/SKILL.md) - per-device service status drill-down
• [organizations](../organizations/SKILL.md) - resolving customer/site org units for sweeps