Keep the RMM you chose. It answers a different question from this one.

CubeMSP and RMM Platforms

Alerts from your RMM raise incidents against the right client, site and device - and close again when the alert clears.

We have no interest in replacing your remote monitoring and management platform. A good RMM is the product of years of agent engineering and we would be foolish to compete with it. What matters is that the alert it raises becomes an incident attached to the right client, the right site and the right service, so that the business consequences of a technical event are visible in the same place as everything else. CubeMSP integrates with RMM platforms through webhooks and the API, in whichever direction each one supports.

What moves

Exactly what is synced, and which way

Being specific about this up front avoids the single most common integration disappointment - discovering after go-live that one field never travelled.

  • Into CubeMSP

    Alerts as incidents

    A monitoring alert creates an incident with the client, site and device resolved automatically, at a priority you map from the alert severity.

  • Into CubeMSP

    Alert clearance

    When the underlying alert clears, the incident is updated or resolved according to your rules, so self-healing events do not leave a queue of phantom work.

  • Into CubeMSP

    Device and asset inventory

    Managed device counts per client, available for reconciliation against the services you are billing for.

  • Out of CubeMSP

    Client and site mapping

    The client and site structure held in CubeMSP exposed through the API, so the two systems agree on who is who rather than maintaining separate lists.

How it behaves

The detail that decides whether it is actually useful

  • Noise filtered before it becomes a queue

    Mapping rules decide which alert types raise an incident, at what priority, and which ones simply log. An RMM that raises a ticket for everything produces a queue nobody reads.

  • Related alerts grouped

    Forty devices at one site going offline together is one incident with forty affected devices, not forty incidents to be closed individually.

  • Device counts reconciled

    Managed endpoints reported by the RMM against endpoints billed as a service. The drift is usually real and usually in the client’s favour.

  • Alerts attached to the service

    An alert on a monitored server attaches to the service that covers it, so recurring faults are visible against what you are contracted to support.

Setting it up

Three steps, done during implementation

  1. Point your RMM’s webhook or notification channel at the CubeMSP endpoint and supply an API key.

  2. Map client identifiers between the two systems - usually a one-off exercise done during migration.

  3. Define which alert types raise incidents and at what priority, then tune it over the first fortnight rather than trying to get it right in advance.

Questions

What people ask about this one

  • Any platform that can send a webhook or be polled through a documented API - which is all the mainstream ones. We build and test the specific mapping for your platform during implementation rather than shipping a directory of connectors we cannot all maintain properly.

  • Not if the mapping is set up properly, and getting that right is part of implementation. Only the alert types you nominate raise incidents; the rest can log against the client without creating work.

  • They can, per alert type. Some alerts are resolved by clearing; others need a human to confirm. You decide which are which.

  • You can, but running two queues means neither one is complete, and the reporting from both becomes unreliable. Our advice is to pick one, and if it is the RMM’s then you probably do not need us yet.

RMM

Check the RMM detail before you commit

Send us the specifics - your chart of accounts, your tax treatment, your product structure - and we will tell you exactly how it maps rather than promising it will be fine.