Getting Started with Site24x7: First Monitor Setup

Getting a basic monitoring setup running in Site24x7 takes about 20 minutes. This walkthrough covers the essential path: create an account, add a website monitor, install the server agent, set up alert contacts, and understand what you're looking at in the dashboard.

Step 1: Create an Account

Site24x7 offers a 30-day free trial with no credit card required. Sign up at site24x7.com and pick the plan tier you want to evaluate — the trial gives you access to all features.

After confirming your email, you land in the Site24x7 portal. The default view shows an empty monitoring dashboard with a getting-started checklist. Skip the wizard — we'll set things up manually so you understand what each piece does.

One important setting to configure first: go to Admin > Account > Time Zone and set it to your local timezone. Alerts and reports display timestamps in this timezone, and getting it wrong causes confusion when correlating incidents with logs from other systems.

Step 2: Add a Website Uptime Monitor

A website monitor is a periodic HTTP check from Site24x7's probe network to your URL. Here's how to add one:

1. Go to Monitors > Website Monitoring > Add Monitor > Website
2. Enter the display name (e.g., "Production Homepage") and the URL (https://yoursite.com)
3. Set Check Frequency to 1 minute for production monitors, 5 minutes for less critical URLs
4. Set Timeout to 30 seconds — increase this only if your site legitimately takes longer
5. Under Monitor From, select multiple probe locations. A good starting set for a global audience: North America (Virginia, California), Europe (London, Frankfurt), Asia-Pacific (Singapore, Sydney)
6. Set Monitor Status Notification Threshold to 2 out of selected locations — this means the check fires an alert only when 2+ locations see the URL as down, filtering single-location blips

Under HTTP Configuration:

• If your site requires authentication, configure it under HTTP Authentication
• If you're checking a page that redirects, enable Follow Redirects
• Set up Content Check to verify a specific string appears in the response body — useful for detecting when your CDN is serving a cached error page that returns 200 but shows wrong content

Save the monitor. Within two minutes, you'll see response time data appearing in the monitor detail view.

Reading the Monitor Detail View

The monitor detail page shows:

• Availability — percentage uptime over the selected period (1 hour, 1 day, 7 days, 30 days)
• Response Time — average and percentiles (P50, P75, P95) broken down by probe location
• Status Timeline — horizontal bar showing green (up), red (down), and yellow (trouble) states over time
• Outages — list of all downtime incidents with start time, duration, and affected locations

The Locations tab breaks response time down by probe location. This is where you spot regional slowness — if your P95 from Singapore is 4x higher than from Virginia, your CDN might not be caching effectively in Asia.

Step 3: Install the On-Premises Agent (Server Monitoring)

To monitor a server, you install the Site24x7 agent on it. The agent runs as a background service, collects metrics every minute, and ships them to Site24x7 over HTTPS on port 443.

Getting the Device Key

Before installing, you need your device key:

1. Go to Admin > Inventory > On-Premises Poller or find it under Monitors > Server Monitoring > Add Monitor > Server Monitor
2. Your Device Key is shown in the installation instructions panel — it looks like a 32-character alphanumeric string

Linux Installation

# Download the installer
curl -s https://staticdownloads.site24x7.com/server/Site24x7InstallScript.sh -o /tmp/Site24x7InstallScript.sh

# Run with your device key
sudo bash /tmp/Site24x7InstallScript.sh -key <YOUR_DEVICE_KEY>

The installer:

• Creates a site24x7 user
• Installs the agent binary to /opt/site24x7/monagent/
• Sets up a systemd service (site24x7monagent)
• Starts the agent and registers with Site24x7

Verify the agent is running:

sudo systemctl status site24x7monagent

Within 2-3 minutes, the server appears in your Site24x7 dashboard under Monitors > Server Monitoring.

Windows Installation

Download the MSI installer from the Site24x7 portal (same install instructions page). Run it as Administrator, entering your device key when prompted. The installer creates a Windows service called Site24x7 Windows Agent.

What the Agent Collects by Default

Without any additional configuration, the agent collects:

• CPU utilization and load
• Memory and swap usage
• Disk space usage per mount point
• Disk I/O (read/write ops, throughput)
• Network interface traffic (inbound/outbound bytes)
• System uptime
• Top processes by CPU and memory

Installing Plugins

Plugins extend the agent to monitor specific services. To monitor MySQL:

# Download the MySQL plugin
cd /opt/site24x7/monagent/plugins/
sudo wget https://raw.githubusercontent.com/site24x7/plugins/master/mysql/mysql.py

# Create the config file
sudo tee /opt/site24x7/monagent/plugins/mysql.cfg << EOF
[mysql]
host = localhost
port = 3306
username = monitoring_user
password = yourpassword
EOF

sudo systemctl restart site24x7monagent

MySQL plugin metrics appear in Site24x7 within the next collection cycle. The Site24x7 plugins GitHub repo has 100+ plugins for common software.

Step 4: Configure Alert Contacts

Monitors without alert routing are useless. Set up at least two notification channels before going to sleep:

Email Alerts

1. Go to Admin > Alerts & Notifications > Alert Contact Groups
2. Click Add Contact
3. Enter name, email address, and your mobile number for SMS
4. Set notification preferences: which alert severities trigger email vs. SMS

PagerDuty Integration

If you're using PagerDuty for on-call:

1. In PagerDuty, create a new Integration on your service and get the Integration Key
2. In Site24x7, go to Admin > Third-Party Integrations > PagerDuty
3. Enter the Integration Key and map severity levels to PagerDuty urgency

Webhook Integration (for Slack, custom systems)

Site24x7 sends a JSON payload to your webhook URL on every alert state change. In Slack, create an incoming webhook URL, then:

1. Go to Admin > Third-Party Integrations > Webhooks
2. Enter your Slack webhook URL
3. Customize the payload template if needed

Assigning Alert Contacts to Monitors

Adding a contact doesn't automatically apply it to monitors. For each monitor:

1. Open the monitor > Edit
2. Under Notification Profile, select or create a profile
3. Notification profiles define: which contacts to alert, at what severity, with what delay, and escalation behavior

Create a "Default Production" notification profile that alerts your email immediately and PagerDuty after 5 minutes of downtime. Apply it to all production monitors.

Step 5: Reading the Dashboard

The main dashboard (Home > Overview) shows your entire monitoring inventory:

• Monitor Summary: Counts for UP, DOWN, TROUBLE, MAINTENANCE states across all monitors
• Current Outages: Live list of monitors currently in DOWN or TROUBLE state
• Alert List: Recent alert history with timestamps

The Reports section is where operational insight lives:

• Availability Report: Select any monitor and date range to see uptime percentage, total downtime duration, and per-outage breakdown
• Performance Report: Response time trends over time
• Summary Report: Rolled-up availability across all monitors — useful for weekly review with stakeholders

Common Mistakes to Avoid

Not setting location thresholds: Leaving the monitor set to alert on failure from a single location means you'll get paged for probe network issues. Always require 2+ locations to confirm downtime.

Skipping content checks: An HTTP 200 from a cached error page looks like success. Add a content check string to verify actual page content is rendering.

Not testing alerts: After setting up PagerDuty, temporarily pause a monitor (put it in maintenance mode), then take it out — this triggers a recovery alert and confirms your alerting pipeline works end-to-end before an actual incident.

Default thresholds on server monitors: The default CPU alert fires at 90% — which is often too late. Lower it to 80% for trouble and 90% for critical. Memory alerts at 80% and 90% are more appropriate for most workloads.

Next Steps

With uptime monitoring and server monitoring running, you have baseline coverage. The next layer to add depends on your stack:

• APM: If you have a web application, adding the APM agent gives you request-level visibility
• Log monitoring: Configure the agent to ship application logs for correlation with performance data
• Synthetic transactions: Script multi-step browser flows (login, checkout, search) to detect functional regressions before users do

The first alert you get from a new monitoring setup is almost always revealing — something you thought was healthy turns out to have been degraded for days.