Loading workspace...
Auroranexis documentation
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.
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.
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.
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.
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.
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. |
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.
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.
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.
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.
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.
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.
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 |
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.
| Health impact disabled on connector |
| Enable health impact where supported on the connector detail configuration. |
| Webhook events not appearing | Incorrect webhook URL or authentication | Regenerate webhook credentials and confirm payload reaches the connector endpoint. |
| False critical events during maintenance | Connector still active during planned downtime | Pause the connector before maintenance; resume after validation checks pass. |
