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.
Core Platform Concepts
Xitoring
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.
See also: Xitoring CLI Documentation • Xitogent Documentation
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.
See also: Server Monitoring Guide • FAQ: Server vs Uptime Monitoring
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.
See also: Auto-Discovery Guide • FAQ: Understanding Auto-Features
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).
See also: Auto-Triggers Guide • FAQ: What are Auto-Triggers?
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.
See also: FAQ: Understanding Fault Tolerance
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.
See also: FAQ: Understanding Root Cause Reports
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.
See also: Notification Roles Guide • FAQ: What are Notification Roles?
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.
See also: Integration Guides • FAQ: What are integrations?
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.
See also: FAQ: SMS notifications are expensive
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
Telegram
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
Widget
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.
See also: Team Management & Collaboration • FAQ: Using Sub-Accounts
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
Xitogent Register Key
Authorization key for registering new servers. Different from full API key—only allows adding servers, not accessing incidents/metrics. Less sensitive.
Generate in: Account → API Access → Generate Xitogent Register Key.
Account Usage
Current consumption breakdown: Servers used, Checks used, SMS remaining this month, Teammates used. Helps monitor approaching plan limits.
Location: Billing → Account Usage.
Billing / Subscription
Payment management, invoices, plan upgrades/downgrades. View current plan, add credit cards, purchase extra SMS, manage auto-renewal.
Location: Account → Billing and Subscription.
Links & Related
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