WYRE-AI/msp-claude-plugins/msp-claude-plugins/connectwise/automate/skills/monitors/SKILL.md
ConnectWise Automate Monitors
ConnectWise Automate monitor management: monitor types (internal, remote, agent, SNMP, script), categories, threshold configuration, templates, assignment methods (computer/group/client), and status evaluation.
- Source repository stars
- 42
- Declared platforms
- 0
- Static risk flags
- 0
- Last source update
- 2026-08-28
- Source checked
- 2026-08-28
Decision brief
What it does: where it fits
ConnectWise Automate monitor management: monitor types (internal, remote, agent, SNMP, script), categories, threshold configuration, templates, assignment methods (computer/group/client), and status evaluation.
Not for
- Tasks that require unconfirmed production actions or broad system permissions.
- Environments where the pinned source and install steps cannot be inspected.
Compatibility matrix
Platform support, with evidence labels
| Platform | Status | Evidence | What to check |
|---|---|---|---|
| Codex | Not declared | No explicit evidence | Portability before use |
| Claude Code | Not declared | No explicit evidence | Portability before use |
| Cursor | Not declared | No explicit evidence | Portability before use |
| Gemini CLI | Not declared | No explicit evidence | Portability before use |
Installation
Inspect first. Install second.
The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.
npx skills add https://github.com/WYRE-AI/msp-claude-plugins --skill "msp-claude-plugins/connectwise/automate/skills/monitors"Inspect the Agent Skill "ConnectWise Automate Monitors" from https://github.com/WYRE-AI/msp-claude-plugins/blob/5005f73ba2f52cd299f58aa6bb79f4e70ae87103/msp-claude-plugins/connectwise/automate/skills/monitors/SKILL.md at commit 5005f73ba2f52cd299f58aa6bb79f4e70ae87103. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.
Workflow
What the source asks the agent to do
- 01
Anti-triggers
A monitor that has already fired — the resulting notification has
A monitor that has already fired — the resulting notification hasResponse and resolution targets — SLA clocks and escalation rulesMapping the network itself — Automate SNMP monitors evaluate a - 02
Key Concepts
See references/fields.md for the complete Monitor, MonitorTemplate, and MonitorStatus field reference.
See references/fields.md for the complete Monitor, MonitorTemplate, and MonitorStatus field reference. - 03
Monitor Types
Review the “Monitor Types” section in the pinned source before continuing.
Review and apply the “Monitor Types” source section. - 04
Monitor Categories
Review the “Monitor Categories” section in the pinned source before continuing.
Review and apply the “Monitor Categories” source section. - 05
Alert Severity Levels
See references/fields.md for the complete Monitor, MonitorTemplate, and MonitorStatus field reference.
See references/fields.md for the complete Monitor, MonitorTemplate, and MonitorStatus field reference.
Permission review
Static risk signals and limitations
No configured static risk pattern was detected
This is not proof of safety. Runtime behavior, indirect dependencies, and hidden external systems are outside the static scan.
Evidence record
Why each signal appears
| Signal | Value | Evidence type | Meaning |
|---|---|---|---|
| Quality score | 91/100 | Computed | Documentation, specificity, maintenance, and trust rules |
| Repository stars | 42 | Source | Repository attention, not individual Skill quality |
| Compatibility | 0 platforms | Source | Declared in the catalog source record |
| Usage guide | automated source guide | Editorial | Generated or reviewed according to the visible evidence level |
Pinned source
Provenance and original SKILL.md
- Repository
- WYRE-AI/msp-claude-plugins
- Skill path
- msp-claude-plugins/connectwise/automate/skills/monitors/SKILL.md
- Commit
- 5005f73ba2f52cd299f58aa6bb79f4e70ae87103
- License
- Apache-2.0
- Collected
- 2026-08-28
- Default branch
- main
View the original SKILL.md
ConnectWise Automate Monitor Management
Overview
Monitors in ConnectWise Automate continuously evaluate conditions on managed endpoints and generate alerts when thresholds are exceeded. This skill covers monitor types, threshold configuration, template management, and assignment strategies.
Anti-triggers
- A monitor that has already fired — the resulting notification has
its own lifecycle, acknowledgment and history; use
connectwise-automate-alerts. - Response and resolution targets — SLA clocks and escalation rules
are ConnectWise PSA ticket behaviour, not Automate thresholds; use
connectwise-psa-tickets. - Mapping the network itself — Automate SNMP monitors evaluate a
threshold on a device you point them at; discovering topology and
watching links between devices is
auvik-networks.
Key Concepts
Monitor Types
| Type | Description | Execution |
|---|---|---|
| Internal Monitor | Runs on the Automate server | Checks agent data |
| Remote Monitor | Runs from the Automate server | Network checks (ping, port, HTTP) |
| Agent Monitor | Runs on the endpoint agent | Local system checks |
| SNMP Monitor | Polls SNMP-enabled devices | Network device monitoring |
| Script Monitor | Executes script for check | Custom logic |
Monitor Categories
| Category | Examples |
|---|---|
| Performance | CPU, memory, disk usage |
| Service | Service status, process running |
| Event Log | Windows Event Log entries |
| Network | Ping, port open, HTTP response |
| Security | AV status, patch compliance |
| Hardware | Drive health, temperature |
| Application | Specific app monitoring |
Alert Severity Levels
| Level | Value | Description |
|---|---|---|
Information | 1 | Informational, no action needed |
Warning | 2 | Potential issue, investigate |
Error | 3 | Failure, action required |
Critical | 4 | Severe issue, immediate action |
See references/fields.md for the complete Monitor, MonitorTemplate, and MonitorStatus field reference.
API Patterns
Monitors are created either from a template (POST /Computers/{computerID}/Monitors with TemplateID) or as a fully custom definition (POST /Monitors with the full threshold/assignment payload). Thresholds always use one of the short operator codes — eq, ne, gt, lt, ge, le, contains, notcontains — not full words like "greater". Assignment targets a Group, Computer, or Client via AssignmentType + TargetID.
GET /cwa/api/v1/Monitors/Status?condition=Status ne 'OK'&pageSize=100
Authorization: Bearer {token}
See references/api.md for the complete endpoint catalog (templates, per-computer monitors, status, create/update/disable/delete, group assignment).
Workflows
Create Disk Space Monitor
async function createDiskSpaceMonitor(client, computerId, options = {}) {
const {
drive = 'C:',
warningThreshold = 15,
criticalThreshold = 5,
checkInterval = 300
} = options;
const monitor = await client.request('/Monitors', {
method: 'POST',
body: JSON.stringify({
Name: `Disk ${drive} Free Space`,
MonitorType: 'Agent',
Category: 'Performance',
CheckInterval: checkInterval,
FailAfter: 1,
ResetAfter: 1,
AlertSeverity: 2, // Warning
Thresholds: [
{
Field: 'DiskFreePercent',
Operator: 'lt',
Value: String(warningThreshold),
Duration: 0
}
],
AssignmentType: 'Computer',
TargetID: computerId
})
});
return monitor;
}
Create Service Monitor
async function createServiceMonitor(client, groupId, serviceName) {
const monitor = await client.request('/Monitors', {
method: 'POST',
body: JSON.stringify({
Name: `Service: ${serviceName}`,
MonitorType: 'Agent',
Category: 'Service',
CheckInterval: 300,
FailAfter: 2,
ResetAfter: 1,
AlertSeverity: 3, // Error
AlertMessage: `Service ${serviceName} is not running on %computername%`,
Thresholds: [
{
Field: 'ServiceStatus',
Operator: 'ne',
Value: 'Running'
}
],
AssignmentType: 'Group',
TargetID: groupId
})
});
return monitor;
}
Get Failing Monitors for Client
async function getFailingMonitors(client, clientId) {
// Get all computers for client
const computers = await client.request(
`/Clients/${clientId}/Computers?pageSize=500`
);
const failingMonitors = [];
for (const computer of computers) {
const monitors = await client.request(
`/Computers/${computer.ComputerID}/Monitors`
);
const failing = monitors.filter(m =>
['Warning', 'Error', 'Critical'].includes(m.Status)
);
if (failing.length > 0) {
failingMonitors.push({
computer: computer.Name,
computerId: computer.ComputerID,
monitors: failing.map(m => ({
name: m.Name,
status: m.Status,
value: m.CurrentValue,
lastCheck: m.LastCheck
}))
});
}
// Respect rate limits
await sleep(100);
}
return failingMonitors;
}
Apply Template to All Servers
async function applyTemplateToServers(client, templateId) {
// Get the template details
const template = await client.request(`/Monitors/Templates/${templateId}`);
// Get all servers
const servers = await client.request(
`/Computers?condition=OS contains 'Server'&pageSize=500`
);
const results = [];
for (const server of servers) {
try {
await client.request(`/Computers/${server.ComputerID}/Monitors`, {
method: 'POST',
body: JSON.stringify({ TemplateID: templateId })
});
results.push({
computer: server.Name,
status: 'applied'
});
} catch (error) {
results.push({
computer: server.Name,
status: 'failed',
error: error.message
});
}
await sleep(100);
}
return {
template: template.Name,
applied: results.filter(r => r.status === 'applied').length,
failed: results.filter(r => r.status === 'failed').length,
details: results
};
}
Monitor Health Summary
async function getMonitorHealthSummary(client) {
const statuses = await client.request('/Monitors/Status?pageSize=1000');
const summary = {
total: statuses.length,
ok: 0,
warning: 0,
error: 0,
critical: 0,
unknown: 0,
disabled: 0,
byCategory: {}
};
for (const status of statuses) {
switch (status.Status) {
case 'OK': summary.ok++; break;
case 'Warning': summary.warning++; break;
case 'Error': summary.error++; break;
case 'Critical': summary.critical++; break;
case 'Unknown': summary.unknown++; break;
case 'Disabled': summary.disabled++; break;
}
// Track by category
const category = status.Category || 'Uncategorized';
if (!summary.byCategory[category]) {
summary.byCategory[category] = { ok: 0, issues: 0 };
}
if (status.Status === 'OK') {
summary.byCategory[category].ok++;
} else {
summary.byCategory[category].issues++;
}
}
summary.healthPercentage = Math.round(
(summary.ok / (summary.total - summary.disabled)) * 100
);
return summary;
}
Error Handling
Common Monitor API Errors
| Error | Status | Cause | Resolution |
|---|---|---|---|
| Template not found | 404 | Invalid TemplateID | Verify template exists |
| Invalid threshold | 400 | Malformed threshold | Check threshold syntax |
| Monitor exists | 400 | Duplicate monitor | Use unique name |
| Permission denied | 403 | No access | Check user permissions |
| Invalid operator | 400 | Bad comparison operator | Use valid operator |
See references/examples.md for a sample error response, a validateMonitorDefinition helper, and ready-made configurations for CPU, memory, service, and ping monitors.
Best Practices
- Use templates - Standardize monitoring across environments
- Set appropriate intervals - Balance responsiveness vs. load
- Configure FailAfter - Avoid alert storms from transient issues
- Use groups for assignment - Easier management than per-computer
- Document thresholds - Record why specific values were chosen
- Test monitors - Validate before broad deployment
- Review regularly - Audit monitors for relevance
- Layer severity - Warning before Error, Error before Critical
- Include context in alerts - Use variables in alert messages
- Plan for maintenance - Disable monitors during scheduled work
Related Skills
- ConnectWise Automate Computers - Monitored computers
- ConnectWise Automate Alerts - Monitor-generated alerts
- ConnectWise Automate Scripts - Script monitors
- ConnectWise Automate API Patterns - Authentication and pagination
Frequently asked questions
What to verify before installation and use
What does the ConnectWise Automate Monitors source document cover?
ConnectWise Automate monitor management: monitor types (internal, remote, agent, SNMP, script), categories, threshold configuration, templates, assignment methods (computer/group/client), and status evaluation.
How do I install ConnectWise Automate Monitors?
The source record exposes this install command: npx skills add https://github.com/WYRE-AI/msp-claude-plugins --skill "msp-claude-plugins/connectwise/automate/skills/monitors". Inspect the command and pinned source before running it.
Alternatives
Compare before choosing
garrytan/gbrain
bulk-ingestion
End-to-end discipline for turning any large data source (audio libraries, email takeouts, document corpora, chat exports, API dumps) into brain pages at scale. The lifecycle spine: SCHEMA → ACCESS → TRIAL → EVALUATE → IMPROVE → CODIFY → TEST → SKILLIFY → BULK → MONITOR. State is tracked in a durable JSON manifest (see MANIFEST-PATTERN.md) so any crash, session boundary, or subagent fan-out resumes from ground truth instead of memory.
alirezarezvani/claude-skills
app-store-optimization
App Store Optimization (ASO) toolkit for researching keywords, analyzing competitor rankings, generating metadata suggestions, and improving app visibility on Apple App Store and Google Play Store. Use when the user asks about ASO, app store rankings, app metadata, app titles and descriptions, app store listings, app visibility, or mobile app marketing on iOS or Android. Supports keyword research and scoring, competitor keyword analysis, metadata optimization, A/B test planning, launch checklist
dotnet/skills
migrate-vstest-to-mtp
Migrates .NET test projects from VSTest to Microsoft.Testing.Platform (MTP). Use when user asks to "migrate to MTP", "switch from VSTest", "enable Microsoft.Testing.Platform", "use MTP runner", set OutputType=Exe only for test projects in Directory.Build.props, or mentions EnableMSTestRunner, EnableNUnitRunner, or UseMicrosoftTestingPlatformRunner. USE FOR: MTP behavioral differences vs VSTest (exit code 8, zero tests discovered, --ignore-exit-code, TESTINGPLATFORM_EXITCODE_IGNORE); centralizing
oaustegard/claude-skills
featuring
Generate hierarchical _FEATURES.md files that describe what a codebase DOES from a user/consumer perspective, anchored to source symbols via tree-sitting. Supports large complex codebases through feature-driven decomposition into sub-feature files. Uses a multi-pass synthesis: orientation → detail → overview rewrite. Use when someone says "what does this do", "document features", "feature inventory", "_FEATURES.md", or needs to understand a codebase's purpose before modifying it. Complements tre