Does NX-Cloud replace all local monitoring?

Not necessarily. In Field + NX-Cloud, the complete hosted monitoring and workflow layer resides in NX-Cloud while Field retains physical acquisition and bounded local continuity. In NX-Cloud Only, facility monitoring and protection must already be independently provided where required. The local boundary is explicitly engineered for each deployment.

Is one NCU a guaranteed performance level?

No. It is a planning envelope under an approved workload model. The mix of items, values, events, logs, cardinality, queries, APIs, retention and failure behavior affects capacity. The order-specific workload test establishes the accepted service envelope.

Can NX-Cloud run in the customer’s cloud or on premises?

Yes, through an approved customer-cloud or private deployment. The order must define hosting responsibility, access, updates, observability, backup, recovery, security, support and lifecycle obligations.

Does a dedicated service cell mean a dedicated physical data center?

Not automatically. A dedicated service cell refers to dedicated service components and an isolated operating boundary as defined by the order. Region, account, cluster, hardware and facility dedication are separate requirements.

Can local NX and NX-Cloud be used together?

Yes. Local NX may remain the local monitoring authority while selected state, data, evidence or portfolio views are federated to NX-Cloud. The design must prevent conflicting ownership and clearly state which layer is authoritative for alarms, workflow and history.

HOSTED MONITORING PROFILES

PrecisionDCMS NX-Cloud Service Profiles

Planning envelopes for hosted monitoring, data, visualization, identity, workflow, evidence and multi-site operations—selected from workload, retention, isolation, connectivity and recovery requirements.

Talk to engineering Request an Architecture Review

Access: Open access
Resource type: Hosted service profile and selection guide
Primary audience: Platform owners, architects, security, procurement, operators and multi-site service teams
Product scope: PrecisionDCMS NX-Cloud and CriticalOps Cloud dependencies

HOSTED MONITORING AUTHORITY

NX-Cloud provides the complete hosted monitoring and operating layer for selected deployments.

PrecisionDCMS NX-Cloud provides hosted collection ingress, monitoring, alarm processing, operational data, visualization, identity, asset and dependency context, workflow, API, reporting, evidence, backup and service operations.

It may serve Field-connected production sites, eligible NX-Cloud-only environments or selected federation from local NX. The architecture identifies which functions are authoritative in NX-Cloud, which local capabilities remain available during impairment and which facility, protection and life-safety systems remain independent.

NX-Cloud does not replace local protection

NX-Cloud can detect and communicate an abnormal condition. It does not become the required local protective device.

COMMON PLANNING ENVELOPE

Capacity is expressed in workload units, then validated for the order.

One NX-Cloud Capacity Unit, or NCU, is a planning envelope of up to 25,000 active normalized monitoring items and 500 sustained new values per second under the approved workload model.

An NCU is not a performance warranty until the order-specific workload test is accepted. High-cardinality accelerator and fabric telemetry, logs, exceptional API cost, unusually expensive preprocessing, long high-resolution retention, large dataset exports and burst event patterns are sized separately.

What counts toward an NCU

Active items

Normalized values actively evaluated, stored or exposed.

Value rate

Sustained newly received normalized values per second.

Exceptional workload

Logs, high-cardinality metrics, expensive queries, streams and transformations.

Accepted workload model

The documented mix, peaks, retention and failure conditions used for validation.

FOUR SERVICE BASELINES

Select capacity and isolation together.

Scroll horizontally to see the full table.

PrecisionDCMS NX-Cloud service profile comparison
Profile	Capacity	Site and user basis	Native retention	Service isolation	Typical planning use
Foundation — NXC-FDN	1 NCU	1–2 sites; 10 named users; 2 collector pools	90 days high resolution; 12-month rollup	Shared multi-tenant with logical isolation	Pilot, small production scope or initial managed deployment
Standard — NXC-STD	4 NCUs	Up to 5 sites; 50 named users; 8 collector pools	180 days high resolution; 24-month rollup	Shared or logically dedicated	Multi-site production or substantial Field-connected environment
Advanced — NXC-ADV	20 NCUs	Up to 20 sites; 250 named users; 32 collector pools	365 days high resolution; 36-month rollup	Dedicated service cell with expanded recovery and connectivity options	Large campus, portfolio or demanding customer-service environment
Private / Sovereign — NXC-PRV	Custom validated envelope	Custom sites, users and collectors	Contract-defined	Dedicated PrecisionX region, customer cloud, on-premises or other approved private deployment	Residency, isolation, regulated, air-gapped-adjacent or exceptional-scale requirements

Reference planning bases, not entitlement

Site, user and collector values are reference planning bases, not automatic entitlement or service-level promises. The executed order and accepted workload model control.

COMPLETE HOSTED SERVICE STACK

A profile combines capacity with the operational services required to run it.

Ingress and collection

Site identity, collector registration, mTLS or approved private connectivity, proxy and collector health, queue visibility, bounded buffering, replay control and source-adapter monitoring.

Monitoring and alarm

Item evaluation, quality and staleness, event normalization, correlation, suppression, dependencies, maintenance state, notification and escalation integration.

Data services

Time-series storage, event ledger, canonical identifiers, schema and profile versions, rollups, retention, exports, dataset services and lineage.

Visualization and portal

Operator dashboards, customer views, technical search, reports, status, scoped asset access and evidence presentation.

Identity and secrets

Named identity, MFA, roles, tenant scope, service identities, certificates, credential handling, privileged access and audit.

Asset and dependency

Site, room, system, equipment, interface, point, service and customer context with versioned operational dependencies.

Workflow and integrations

Incident, work, maintenance, change, vendor, ticketing, webhook, API, notification and external-platform integration.

Service operations and recovery

Monitoring of the service, backup, restore, capacity, vulnerability and lifecycle operations; continuity, disaster recovery and customer communication according to the selected profile.

DEPLOY WHERE THE SERVICE BOUNDARY REQUIRES

NX-Cloud is available in multiple isolation patterns.

Shared multi-tenant

Shared service infrastructure with logical tenant isolation, scoped identity and data access. Suitable only where the accepted workload, security and contractual requirements permit it.

Logically dedicated

A more isolated logical service boundary with dedicated or constrained service components as defined by the order, while retaining selected shared platform services.

Dedicated service cell

Dedicated monitoring and data service components for a customer, campus or portfolio, with order-specific connectivity, recovery, maintenance and capacity controls.

Dedicated PrecisionX region

A separately operated regional environment for defined residency, scale or customer isolation requirements.

Customer cloud

PrecisionDCMS service components deployed into an approved customer-controlled cloud environment with a documented shared-responsibility and lifecycle model.

Customer-hosted private or sovereign

A private deployment designed for residency, isolation or exceptional operational constraints. Hosting, updates, support access, backup, disaster recovery and responsibility must be explicitly defined.

PRIVATE, OBSERVABLE PATHS

Collection is designed around outbound or private connectivity and bounded degraded modes.

Supported patterns:

Outbound mutual TLS
Customer VPN
NetBird or another approved zero-trust network-access path
Private WAN or cloud interconnect
Collector-local source access
Dedicated service-cell connectivity
Controlled store-and-forward and replay

Endpoints are not made publicly reachable

Local controllers, BMCs and management endpoints are not made publicly reachable in order to use NX-Cloud. Collectors and approved access paths are placed within documented zones and conduits with least privilege, source restrictions, named administration and auditable change.

DEGRADED-MODE BEHAVIOR

Every impairment has a defined planning behavior.

Scroll horizontally to see the full table.

NX-Cloud impairment and required planning behavior
Impairment	Required planning behavior
Source unavailable	Preserve last quality and source state; mark stale or bad according to contract; do not infer normal state
Collector unavailable	Alarm collector health; preserve source distinction; fail over or queue only as designed
WAN or tunnel loss	Field or local systems continue according to design; collectors buffer within accepted capacity; NX-Cloud marks stale; direct local response paths remain available
Hosted service impairment	Execute the selected service-cell recovery and customer-communication plan; local protection remains independent
Event storm	Protect critical evaluation and queues through correlation, suppression, prioritization and bounded backlog
Identity service impairment	Existing sessions and controlled emergency access follow policy; new privileged access may be restricted; break-glass remains audited
Regional disaster	Execute the contract-defined service-cell, restore, DNS, certificate, validation and customer-communication sequence

SELECT THE PROFILE FROM THE SERVICE REQUIREMENT

Capacity, isolation and recovery must be evaluated together.

Number and type of sites
Active normalized items
Sustained and peak values per second
Logs, events and high-cardinality sources
Collector pools and geographic distribution
Named and concurrent users
Tenant and customer-view requirements
High-resolution and rollup retention
Report, API, stream and export demand
Asset and dependency scale
Workflow and integration volume
Shared, logical, dedicated or private isolation
Data-residency and customer-cloud requirements
Connectivity type and diversity
Buffering and replay outage requirement
Backup, restore and recovery objectives
Maintenance and change windows
Service-hours, field-response and operating-tier requirements
Growth horizon and reprofile trigger
Order-specific performance and failure testing

The service-profile guide includes

NCU definition and workload boundaries
Foundation, Standard, Advanced and Private/Sovereign profiles
Service-group architecture
Field + NX-Cloud, NX-Cloud Only and local-NX federation patterns
Shared, logically dedicated, dedicated and private deployment models
Connectivity and collector patterns
Local-continuity and store-and-forward considerations
Retention and data-location decisions
Identity, tenant and customer-view considerations
Backup and disaster-recovery planning
Sizing worksheet
Profile-change and growth triggers
Order-specific validation inputs

Frequently asked

Questions and answers

Does NX-Cloud replace all local monitoring?: Not necessarily. In Field + NX-Cloud, the complete hosted monitoring and workflow layer resides in NX-Cloud while Field retains physical acquisition and bounded local continuity. In NX-Cloud Only, facility monitoring and protection must already be independently provided where required. The local boundary is explicitly engineered for each deployment.
Is one NCU a guaranteed performance level?: No. It is a planning envelope under an approved workload model. The mix of items, values, events, logs, cardinality, queries, APIs, retention and failure behavior affects capacity. The order-specific workload test establishes the accepted service envelope.
Can NX-Cloud run in the customer’s cloud or on premises?: Yes, through an approved customer-cloud or private deployment. The order must define hosting responsibility, access, updates, observability, backup, recovery, security, support and lifecycle obligations.
Does a dedicated service cell mean a dedicated physical data center?: Not automatically. A dedicated service cell refers to dedicated service components and an isolated operating boundary as defined by the order. Region, account, cluster, hardware and facility dedication are separate requirements.
Can local NX and NX-Cloud be used together?: Yes. Local NX may remain the local monitoring authority while selected state, data, evidence or portfolio views are federated to NX-Cloud. The design must prevent conflicting ownership and clearly state which layer is authoritative for alarms, workflow and history.

Related resources

Hardware and Configuration

SIZE THE HOSTED OPERATING LAYER

Establish the workload, isolation and recovery envelope.

Share the source mix, scale, retention, users, connectivity, residency and operational requirements. PrecisionX will identify the appropriate service profile and any order-specific validation work.

Request an Architecture Review Talk to engineering