Glossary

Complete reference of Xitoring terminology. Each term includes a concise definition and context. Use this to understand concepts mentioned throughout documentation and dashboard.

Tips

Can't find a term? Use your browser's find (Ctrl+F or Cmd+F) to search this page. Or check the FAQ for common questions.

All-in-one infrastructure monitoring platform combining server monitoring, uptime checks, SSL monitoring, and status pages in a single dashboard. Starts at $4.99/month. Unlike competitors charging separately for each feature, Xitoring bundles everything affordably.

See also: Getting Started • FAQ: What is Xitoring?

Xitogent

Go-based agent built for performance and lightweight monitoring. Installed directly on your servers to collect metrics: CPU, memory, disk, I/O, processes, and integration-specific data. Minimal resource footprint (< 1% CPU, < 50MB memory). Auto-updates without interrupting monitoring.

Example: One command installs Xitogent on Linux/Windows; it then auto-registers and starts collecting data.

See also: Xitogent Documentation • FAQ: What is Xitogent?

Xitoring CLI

Command-line interface for interacting with Xitoring from the terminal (similar to Azure CLI or Google Cloud CLI). Manage servers, checks, triggers, incidents, integrations, and sub-accounts without using the dashboard. Useful for automation, scripting, and bulk operations.

Not the same as Xitogent: This is a control/management tool, not the monitoring agent.

Example: xitoring check create to add uptime checks; xitoring server list to view all servers; xitoring integrate enable mysql to enable integrations.

Xitoring API

REST API providing programmatic access to create/manage servers, checks, triggers, incidents, integrations, sub-accounts. Authenticate with API keys from Account → API Access.

Example: POST /v1/checks to create new uptime check; GET /v1/incidents to fetch open incidents.

See also: API Documentation • FAQ: Using the API

Monitoring Types

Server Monitoring

Real-time metrics collected from inside your servers via Xitogent. Measures: CPU load, memory usage, disk space, disk I/O, network traffic, running processes. Updates every minute. Requires Xitogent installed.

Use for: Detecting resource exhaustion before it crashes your app; understanding what's consuming resources.

Uptime Monitoring (Checks)

External availability tests from global nodes simulating user access. Tests: HTTP(S), DNS, Ping, TCP, UDP, FTP, SMTP, IMAP, POP3, Heartbeat. Shows response time and uptime %. No agent required—requires only network access to your service.

Use for: Verifying users can reach your service; detecting outages from outside your network.

See also: Uptime Monitoring Guide • All Check Types

Synthetic Monitoring

Proactive testing of services from external locations to detect issues before users encounter them. Includes HTTP, API, and heartbeat checks. Distinct from observability (which is reactive—looking at logs after problems).

Example: Every minute, external node in Singapore tests your API and measures response time.

API Monitoring

Advanced HTTP checks for monitoring REST APIs with support for custom headers, request bodies, authentication, response parsing. Goes beyond basic HTTP status code checking.

Example: Monitor /api/v1/users endpoint with Authorization: Bearer token header and check for specific JSON response.

See also: HTTP Check Guide

SSL Monitoring

Certificate lifecycle monitoring tracking expiration dates, validity status, revocation, and chain health. Proactive alerts 30/14/7/1 days before expiration prevent embarrassing "untrusted certificate" errors.

Use for: Preventing SSL expirations that browsers block as unsafe; ensuring encryption stays valid.

See also: SSL Monitoring Guide

Heartbeat Monitoring

Verification that scheduled tasks or cron jobs executed successfully. External URL you define; script calls it on completion. If URL isn't called within expected interval, incident fires.

Example: Database backup cron job calls https://monitor.example.com/heartbeat/backup daily at 2 AM. If job dies, XitorIng detects it within minutes.

See also: Heartbeat Guide

Cronjob Monitoring

Specialized heartbeat for cron jobs with additional features like timeout detection and execution logs. Simpler than generic heartbeat setup.

Example: Monitor that mysqldump backup completes within 30 minutes each night.

Automation Features (Xitoring Differentiators)

Auto-Discovery

Xitogent automatically scans your server to find running services and software (Nginx, Apache, MySQL, Redis, Docker, etc.), creates uptime checks, and shows integration recommendations in the server view. Saves hours of manual service detection.

Timeline: Occurs 5-10 minutes after server registration. Once complete, uptime checks are created and discovered services are listed with recommendations.

Auto-Trigger

Xitoring automatically creates recommended monitoring triggers based on detected services and metric baselines. System learns your "normal" and suggests alerts for abnormal conditions. Reduces manual trigger setup from hours to minutes.

Example: Detects MySQL with 50-connection average → creates trigger "alert if MySQL connections > 150" (3x baseline).

Auto Fault Tolerance

System automatically adjusts Fault Tolerance temporarily during unstable periods to reduce false alerts from brief blips. When stability returns, reverts to configured FT.

Example: Server is flaky with brief disconnects; system raises FT from 1 to 5 minutes temporarily, preventing alert spam. Once stable for 30 minutes, returns to 1 minute.

See also: Auto Fault Tolerance Guide

Auto-Update

Xitogent automatically updates itself when new versions available, without interrupting monitoring or requiring manual restart. Happens in background during low-traffic windows.

Benefit: Always running latest version with security patches without you thinking about it.

Monitoring Configuration & Core Concepts

Trigger

Rule defining when an Incident should be created. Specifies: what condition to check, what threshold triggers alert, Fault Tolerance, and Notification Roles to alert.

Examples:

HTTP check: "if response time > 5000ms, create incident"
Database: "if slow query count > 10, create incident"
Server: "if CPU usage > 85%, create incident"

See also: FAQ: Understanding Triggers

Fault Tolerance (FT)

Time buffer (in minutes) before incident is reported to prevent false alerts from brief network blips. Default 1 minute means service must be down for 1 full minute before alert fires.

Why it matters:

FT = 1 min: Alert quickly (catch real problems fast)
FT = 5 min: Miss brief blips (less alert fatigue)
FT = 15 min: Very forgiving (might miss real issues)

Typical values: 1-5 minutes for most services.

Incident

Alert event created when trigger condition is met. Includes root cause details explaining WHY it happened (unique Xitoring feature). Triggering Notification Roles to alert users.

Lifecycle: Created → Notification sent → Investigated → Resolved.

Example: "Incident: HTTP response time 8000ms (> 5000ms threshold) for Response Time=8sec due to high database load (MySQL CPU 95%)."

See also: Incidents Guide

Root Cause Report

Detailed explanation of WHY an incident occurred (unique Xitoring feature). Instead of just "service down", shows the specific technical reason: "SSL certificate expired", "Database query timeout", "CPU 100% from runaway process", etc.

Impact: Reduces incident resolution time by ~50% on average because engineers immediately know what to fix.

Notification Role

Definition of WHO gets alerted, HOW (channel), and WHEN (schedule). Assigned to triggers to determine who receives incident notifications.

Example Roles:

"Engineering Team": Email + Slack, anytime
"OnCall": SMS + PagerDuty, 24/7
"Manager": Email only, business hours

Channels: Email, SMS, Voice, Slack, Teams, Discord, Telegram, PagerDuty, Webhook, Zapier, etc.

Check

Individual monitoring task (one surveillance point). Examples: "ping google.com every 1 minute", "test https://api.example.com every 5 minutes", "query MySQL database every 1 minute".

Each check has:

Target (hostname, URL, port)
Interval (how often to test: 1-60 minutes)
Triggers (rules that create incidents)

See also: All Check Types

Check Label

Custom human-readable name for a check to make it easily identifiable in dashboard. Examples: "Production API - /users endpoint", "Database Backup Status", "CDN Edge Node".

Response Time

Milliseconds (ms) taken for service to respond. Used in trigger conditions: "alert if response time > 5000ms" (5 seconds).

Typical thresholds:

Web app: 1000-5000ms (1-5 seconds, varies by service)
API: 500-2000ms (faster expected)
Database: 50-200ms (very fast)

Status Code

HTTP response code indicating request outcome:

2xx (Success): 200 OK, 201 Created, etc. — service working
3xx (Redirect): 301 Moved, etc. — service redirecting
4xx (Client Error): 400 Bad Request, 404 Not Found, 401 Unauthorized — client or auth issue
5xx (Server Error): 500 Internal Server Error, 503 Service Unavailable — service broken

Common checks: Verify site returns 200 (success) not 500 (error) or 503 (down for maintenance).

Condition

Specific part of a trigger defining what to check. Examples:

"Response code is 200"
"Response body contains 'success'"
"Response time less than 5000ms"
"Database query returns zero errors"

Infrastructure & Deployment

Server

Physical or virtual machine you're monitoring. Must have Xitogent installed to collect metrics. Registers with unique API key; appears in Servers list in dashboard.

Example: Your production web server 192.168.1.100 with Nginx, MySQL, and PHP-FPM running.

Hostname

Domain name or IP address of your service being monitored. Used in uptime checks and integrations.

Examples:

Domain: api.example.com, database.internal.company.com
IP: 192.168.1.10 (private), 1.2.3.4 (public)

Port

Network endpoint on server where service listens. Different services use different ports:

80: HTTP web traffic
443: HTTPS web traffic
3306: MySQL database
5432: PostgreSQL database
27017: MongoDB database
6379: Redis cache
25/587/465: SMTP email

Xitoring allows custom ports for non-standard configurations.

Node / Monitoring Region

Geographic location from which external uptime checks originate. Xitoring has 15+ global nodes (LAX, NYC, London, Singapore, etc.). Each check can test from one or multiple nodes to detect regional issues.

Why multiple nodes matter: If check fails from 2/3 nodes, likely real issue. If fails from 1 node only, likely node problem or local ISP issue.

See also: Monitoring Locations

Global Probing Nodes

Distributed network of servers worldwide from which Xitoring performs uptime checks. Ensures reliable detection even if one region has ISP issues. Auto-selects nearest node for fastest response.

Benefit: Catches outages before customers in other regions even notice, plus detects geographic failures (e.g., "CDN slow in Asia").

Group

Organizational category for servers/checks (e.g., "Production", "Staging", "Backup", "Database Cluster"). Helps organize large deployments.

Sub-Group: Nested within Group (e.g., Production → Web Tier, Production → Database Tier).

Gateway / Proxy

Alternate network route for communicating with servers if direct connection unavailable (firewalled internal services, VPNs). Xitogent can route through gateway; uptime checks can use HTTP proxy.

Integrations & Metrics (The +30 Ecosystem)

Integration

Pre-configured monitoring for specific software eliminating need to set up custom monitoring by hand. Each integration collects relevant metrics and suggests triggers.

Database Integrations: MySQL, PostgreSQL, MongoDB, CouchDB, Redis, KeyDB, InfluxDB, SQLServer

Web/App Server Integrations: Nginx, Apache, IIS, PHP-FPM, HAProxy, Varnish, LiteSpeed, OpenLiteSpeed

Message Queue Integrations: RabbitMQ, Kafka

Other Integrations: Docker, CoreDNS, Netstat, WireGuard, OpenVPN, Supervisor, Dovecot, Postfix, Exim

Setup: Interactive CLI command walks through configuration. Via dashboard: Servers → Integrations → Enable for your software. Credentials encrypted in transit and stored securely.

Metrics

Time-series data collected from servers (CPU%, memory%, disk I/O, network traffic, process counts). Displayed as graphs. Used in trigger conditions causing incidents when thresholds exceeded.

Common metrics:

CPU Load (% usage)
Memory Usage (% and absolute MB/GB)
Disk Space (% used, free)
Disk I/O (read/write operations per second)
Network Traffic (incoming/outgoing Mbps)
Process Count, Connection Count

Live Statistics

Real-time metric display refreshing every few seconds. Useful during troubleshooting: watch CPU spike, memory grow, disk fill as you test.

Location: Server page → Live Statistics tab.

Graphs

Visual representation of metrics over time. X-axis: time (past hour/day/week/month). Y-axis: metric value. Helps spot trends (CPU slowly climbing, sudden spike, etc.).

Example: CPU graph shows baseline 20%, then spike to 95% at 3 PM → coincides with batch job starting.

Alerts & Communication

Email Notification

Free notification channel included in all plans. Unlimited emails, no character limits. Each role can have multiple email addresses. Custom emails require confirmation (click link in email) before alerts deliverable.

Good for: Primary alert channel for all users.

SMS Notification

Text message alerts. Included in plan limits (varies: 20-500/month). Additional SMS via "Extra SMS" packages ($10 per 100). Each SMS = 1 credit; voice calls also use SMS credits.

Good for: Critical incidents or on-call engineers who need mobile alerts. Caution: SMS consumes paid credits—use sparingly.

Voice Call Notification

Phone call alerts. Uses same credit as SMS (1 call = 1 credit). System calls and delivers message via TTS (text-to-speech) or pre-recorded message.

Good for: Critical production incidents during off-hours when SMS might be missed.

Webhook

Custom HTTP endpoint you control to receive incident notifications. You define format and what happens (email blast, Slack post, SMS via Twilio, call external system, etc.).

Example: POST to your endpoint with incident JSON; your system triggers custom workflow.

See also: Webhook Integration

Slack Integration

Send alerts to Slack channels or DMs. Requires authorizing Xitoring app in Slack workspace. Supports rich formatting (incident details, graphs, links).

Good for: Team visibility and discussion. All team members see incidents in shared channel.

See also: Slack Integration Guide

Microsoft Teams

Send alerts to Teams channels. Two options: legacy webhook or new app integration. New app recommended for richer features.

Good for: Microsoft-centric organizations using Teams as primary communication.

See also: Teams Integration Guide

Discord

Send alerts to Discord servers/webhooks. Integrates richly with Discord formatting.

Good for: Gaming companies, developer communities, technical teams using Discord.

See also: Discord Integration Guide

Send alerts via Telegram bots. Create bot, get token, configure in Xitoring.

Good for: Users preferring Telegram; useful in regions where SMS unreliable.

PagerDuty

Enterprise incident management platform integration. Escalates critical incidents through on-call schedules.

Good for: Large teams with formal on-call rotations and escalation policies.

See also: PagerDuty Integration Guide

Zapier

Connect Xitoring to 5000+ apps (Salesforce, Jira, Airtable, Google Sheets, webhook, etc.). Trigger Zap on Xitoring incident.

Example: Incident → Auto-create Jira ticket → Add to spreadsheet.

See also: Zapier Integration Guide

Extra SMS

Additional SMS credit packages purchased when plan balance depleted. $10 per 100 SMS. Credits don't expire (unlike monthly plan SMS which resets).

Good for: Budget-conscious teams dealing with occasional spike in incidents.

Management & Visibility

Incidents Overview

Dashboard showing all open/resolved incidents across all servers and checks. Real-time updates. Filterable by status, server, check type, date, etc.

See also: Incidents Guide

Incident History

Log of all past incidents with timestamps, duration, root causes. Useful for post-incident analysis and SLA tracking.

Open Incident

Active incident requiring attention. Prevents new similar incidents while existing one open (no duplicate alert spam). Mark as resolved to re-enable alerting.

Resolved Incident

Past incident that's been fixed and manually closed. No longer triggers alerts. Included in SLA/uptime calculations (as downtime).

Incident Note

Comment/annotation added to incident during troubleshooting. Helps team coordinate: "Restarted database", "Waiting on vendor", "Root cause: Out of disk space".

Manual Resolve

Manually closing an incident (usually after confirming the fix applied). Creates resolved incident record for SLA tracking.

Incident Policy

Rules for how incidents grouped, escalated, resolved. Control incident deduplication, escalation timing, repeat incident handling.

See also: Incident Policy Guide

Status Page

Public or private page showing service status and incident history. Displays uptime %, current incidents, maintenance windows. URL shareable with customers.

Public: Anyone with link can view. Private: Password-protected.

Customization: Logo, colors, theme, included checks, announcements.

See also: Status Page Guide • FAQ: Creating Status Pages

Custom Domain

Custom domain for status page instead of default Xitoring subdomain. Example: status.yourcompany.com instead of yourcompany.xitoring.com.

Requires: Custom domain DNS configured to point to Xitoring.

Maintenance Schedule

Planned downtime window where monitoring is paused and downtime doesn't count toward SLA. Prevents false incidents during maintenance.

Example: Database migration 2024-03-15 2-4 AM → create maintenance schedule → Incidents suppressed, status shows "Maintenance" instead of "Down".

See also: Maintenance Schedule Guide

Dashboard

Main monitoring interface showing servers, checks, incidents, metrics, graphs. Customizable with widgets based on role.

Custom Dashboard

Personalized dashboard with selected widgets for specific team. Different from main dashboard.

Example: Database team sees only MySQL/PostgreSQL graphs; DevOps team sees uptime and server status.

See also: Custom Dashboards Guide

Individual card/component on dashboard (metric graph, incident list, status card, server list, etc.). Customizable size, position, refresh interval.

Sub-Account

Teammate account with configurable access. Can have full access, restricted (only assigned servers), or read-only (view only). Each has separate login.

Use case: Alice manages database servers; Bob manages web servers; both use same billing account but see only their servers.

API Access

API key for programmatic platform access. Less powerful than your main password. Use for: automation, CI/CD integration, custom tools. Regenerate if compromised.

Location: Account → API Access tab.

See also: API Documentation

Quick Navigation:

FAQ & Troubleshooting - Common questions and problem-solving
Documentation - Full guides for every feature
Pricing - Plans and pricing
Blog - Articles and best practices

Need help? Create a support ticket or email support@xitoring.com