Auroranexis

Monitoring helps your team observe configured checks and external signals tied to clients. Connectors represent monitoring sources; events record detected conditions with severity and status. Summaries on client detail pages and the Monitoring module support early awareness alongside health scores and incidents, so operators can escalate before clients report problems.

Overview

The Monitoring module lists connectors configured for your organization—each linked to a client where applicable. Connectors support providers such as Manual entry, Webhook, HTTP checks, Healthcheck, and common integration targets. Events capture severity, message, detection time, and resolution status.

Client detail pages include a monitoring summary card showing recent activity for linked connectors. Critical events can affect client health scores and may optionally trigger incident or risk creation based on connector configuration such as create incident on critical.

Connector status reflects operational health of the check itself—active, paused, failed, disabled, or archived. A failed connector may indicate configuration or reachability problems rather than client system outage; investigate before ignoring subsequent events.

Monitoring complements but does not replace incident management. Events provide signals; incidents document client impact with SLA timers and optional portal visibility when your team confirms delivery is affected.

Purpose

Agencies often monitor client systems, integrations, or delivery checkpoints outside a single ticket queue. Centralizing monitoring signals in Auroranexis places them next to SLA status, incidents, and reports—the same context operators use for client conversations.

Documented escalation from monitoring events to incidents preserves timeline integrity and supports post-incident analysis. When a critical HTTP check fails and your team opens an incident within minutes, SLA metrics and client summaries reflect a coherent story.

Portfolio-level monitoring usage is constrained by plan limits in Settings → Usage. Planning connector allocation per client tier prevents surprise blocks during onboarding spikes.

Core Concepts

Connectors

A connector defines what you monitor and how checks run. Each connector has a provider type, status, and configuration including the linked client, endpoint or webhook details, and optional automation such as creating incidents on critical events or enabling health impact tracking.

Events

Event fields and values

Concept	Description
Severity	Low, Medium, High, or Critical—guides triage priority and optional automation.
Status	Open while active, Resolved after remediation, Ignored for benign or duplicate signals.
Detection time	When the connector recorded the condition; used in timelines and client summaries.
Client linkage	Events inherit client context from connector configuration for portfolio reporting.

Health impact

Critical monitoring events apply penalties to client health scores when health impact is enabled.

Features

Monitoring list with connector status and last check timestamps.
Create and configure connectors with client linkage.
Multiple provider types including Manual, Webhook, HTTP, and Healthcheck.
Event history with severity, status, and detection time.
Client monitoring summary on client detail pages.
Optional automatic incident creation on critical failures.
Optional health impact tracking on supported connector configurations.
Activity logging for connector and event changes.
Usage limits visible in Settings → Usage.
Pause and resume connectors without deleting configuration history.
Resolve or ignore events with status workflow.
Integration with Operations Command Center portfolio signals.
Escalation alignment via Settings → Escalation for critical event patterns.
Plan-gated connector counts enforced at organization level.

Step-by-step usage

Review Settings → Usage to confirm available monitoring connector capacity.
Open Monitoring and review existing connectors for your portfolio.
Create a connector, select provider type, and link it to the relevant client.
Configure endpoint URL, webhook secret, or manual check parameters per provider documentation.
Set options such as create incident on critical and health impact if appropriate for the client tier.
Enable the connector and confirm status shows active after successful checks.
Review events on the Monitoring detail view and client summary card during daily standup.
Triage open critical events—open Incidents → New incident when client impact is confirmed.
Resolve events after remediation is complete with notes if your playbook requires them.
Ignore benign or duplicate events after documenting why no action was required.
Pause connectors during planned maintenance to avoid false critical events.
Upgrade via Settings → Billing if connector limits block new client onboarding.

Best Practices

Treat monitoring as a signal layer, not a notification firehose. Agencies that define severity thresholds and on-call response in advance respond faster than those that open incidents for every transient blip.

Define which clients require active monitoring versus periodic manual review.
Document escalation paths from monitoring signals to incidents in your runbook.
Pause rather than delete connectors when temporarily disabling checks.
Review monitoring usage before onboarding many new clients on the same plan.
Align critical event handling with on-call coverage and Settings → Escalation rules.
Investigate repeated failed connector status before ignoring events.
Link each connector to exactly one client for clear portfolio reporting.
Name connectors consistently so staff identify production versus staging checks.
Test webhook endpoints after credential rotation to prevent silent failures.
Review ignored events monthly to ensure triage criteria remain valid.

Examples

Marketing agency

A marketing agency runs HTTP checks on client landing pages during campaign launches, links connectors to Active clients, and triages Medium events during business hours. Critical failures during live campaigns trigger incidents with portal summaries for affected clients.

AI automation agency

An automation agency configures Webhook connectors receiving alerts from external uptime tools, maps events to the correct client, and enables create incident on critical for production workflows. Staff resolve events after confirming automated remediation succeeded.

MSP

An MSP deploys Healthcheck connectors across Premium client infrastructure, hits plan limits at forty connectors, and upgrades through Settings → Billing. Critical events feed on-call rotation paired with Settings → Escalation for breach-adjacent response.

Consultancy

A consultancy uses Manual connectors to record milestone checkpoints on short engagements without persistent infrastructure monitoring. Events provide audit trail context in monthly reports without automatic incident creation.

Enterprise deployment

A large agency standardizes connector naming by region and environment, disables health impact on staging checks, and requires incident linkage within thirty minutes for unresolved Critical events on tier-one clients.

Troubleshooting

Common monitoring module issues

Problem	Cause	Solution
Cannot create new connector	Monitoring limit reached on plan	Upgrade via Settings → Billing or archive unused connectors.
Summary empty on client detail page	No linked connectors or recent events	Confirm connectors reference the client and have completed at least one check.
Connector status shows failed	Invalid URL, credentials, or network block	Verify endpoint configuration and reachability from your deployment environment.
Events not creating incidents	create incident on critical disabled	Enable the option on connector configuration and confirm severity threshold.
Health score unaffected by events

FAQ

What is the difference between a connector and an event?: A connector is the configured monitoring source. An event is a single detected condition recorded by that connector with severity and status.
Can one connector monitor multiple clients?: Connectors are linked to one client in configuration. Create separate connectors per client for clear portfolio reporting and health impact.
Do monitoring events appear in the client portal?: Monitoring detail is primarily internal. Client-facing impact is usually communicated through incidents, reports, or portal summaries you choose to share.
How often do checks run?: Check interval depends on connector provider and configuration. Review last check timestamps on the connector detail page for actual frequency.
Should I ignore or resolve an event?: Resolve when remediation is complete. Ignore for benign or duplicate signals after documenting why no action was required.
Where do I see monitoring usage against my plan?: Open Settings → Usage to view connector consumption and limits for your subscription tier.

Need help?

Contact support@auroranexis.com for onboarding support, billing questions, or product guidance. Include your workspace name, the module you are working in, and a brief description of your goal so we can respond efficiently.

Provider types

Manual entry supports ad hoc signals your team records. Webhook receives payloads from external tools. HTTP and Healthcheck run scheduled reachability or endpoint validation. Choose the provider that matches how your agency already observes client systems.