Server Management Guide #

Complete guide to adding, configuring, and managing server monitoring through the admin interface.

Dashboard Overview #

The Servers dashboard provides a comprehensive view of all monitored endpoints:

Scoreboard Metrics #

  • Tracked: Total number of monitored servers
  • Online: Servers returning success status codes
  • Offline: Servers returning failure status codes
  • Average Uptime: Overall uptime percentage (paid plans only)

List Features #

  • Color-coded rows: Green for online, red for offline
  • Real-time status: Current HTTP status codes
  • Uptime percentages: Historical availability data
  • Last checked: Timestamp of most recent check
  • Advanced filtering: By status, archived state, or failures only

Adding Servers #

1. Create New Server #

Navigate to Servers → New Server

Required Fields:

  • Title: Descriptive name for the server (e.g., "Production Website")
  • Endpoint: Full URL to monitor (e.g., "https://example.com")

Optional Fields:

  • Response Body Validation: Validate response content using:
    • contains: Check if response body contains a string
    • not_contains: Check if response body does NOT contain a string
    • regex: Match response body against a regular expression

Supported Protocols:

  • https:// - Recommended for production
  • http:// - Supported but less secure

2. Server Validation #

The system validates:

  • URL format: Must be valid HTTP/HTTPS URL
  • Organization limits: Checks plan server limits
  • Subscription status: Active subscription required

3. Immediate Monitoring #

Once saved:

  • Immediate check: First status check queued instantly
  • Regular checks: Added to monitoring schedule
  • Uptime tracking: Begins calculating availability

Response Body Validation #

Overview #

Response body validation allows you to go beyond simple HTTP status code checks by inspecting the actual content returned by your endpoints.

Validation Types #

Contains Check:

Type: contains
Value: "healthy"

Server is marked UP only if the response body contains "healthy".

Not Contains Check:

Type: not_contains
Value: "error"

Server is marked UP only if the response body does NOT contain "error".

Regex Match:

Type: regex
Value: /status["\s:]+ok/i

Server is marked UP only if the response body matches the regex pattern.

Use Cases #

  • Health Check Endpoints: Validate JSON responses contain "status": "ok"
  • Database Connectivity: Check for "connected" in health responses
  • Error Detection: Fail if response contains "maintenance" or "error"
  • Version Verification: Match specific version strings in responses

Bulk Import (Paid Plans Only) #

Overview #

Organizations on paid plans (Basic, Pro, Enterprise) can bulk import servers using CSV files.

Requirements #

  • Active paid subscription (Basic, Pro, or Enterprise)
  • Available server slots within plan limits
  • CSV file with proper format

CSV Format #

The CSV file must contain two columns:

  • title - Server name/description
  • endpoint - Full URL to monitor (http:// or https://)

Example CSV:

title,endpoint
Production Website,https://www.example.com
API Server,https://api.example.com
Database Health Check,https://db.example.com/health
Staging Environment,https://staging.example.com

Server List Management #

Viewing Servers #

Standard Users: See only their organization's servers Albright Labs Staff: Can view all servers across organizations

List Actions #

Individual Server Actions:

  • Preview: View server details and history
  • Edit: Modify title or endpoint
  • Archive: Soft delete (preserves history)
  • Delete: Permanent removal (archived servers only)

Bulk Actions:

  • Select multiple servers with checkboxes
  • Archive/restore/delete in batches
  • Actions shown based on filter state

Filtering Options #

By Status:

  • All servers
  • Specific HTTP status codes (200, 404, 500, etc.)
  • Online only (success codes)
  • Offline only (failure codes)

By Archive State:

  • Active servers (default)
  • Archived servers
  • Toggle between views

Advanced Filters:

  • "Failed only" - Shows servers with failure codes
  • Search by title or endpoint

Server Details View #

Server Information #

Basic Details:

  • Server title and endpoint
  • Current status with color-coded badge
  • Last checked timestamp

Performance Metrics (Paid Plans):

  • Uptime percentage
  • Status change history
  • Performance trends

Status History #

Log Entries (Paid Plans):

  • Complete timeline of status changes
  • Timestamps for each transition
  • Status change descriptions
  • Searchable and filterable

Free Plan Notice:

  • Logs and uptime statistics locked
  • Upgrade message with plan comparison
  • Direct link to billing page

Plan-Based Features #

Free Plan (1 User, 50 Servers) #

  • Basic server monitoring
  • 5-minute check frequency
  • Email notifications (1 user)
  • No uptime statistics
  • No status history logs
  • No SMS notifications
  • All free plan features
  • 1-minute check frequency
  • Full uptime statistics
  • Complete status history
  • SMS notifications
  • Extended server limits
  • Priority support

Understanding Status Codes #

Success Codes (Green) #

  • 100: Continue
  • 200: OK (most common)
  • 201: Created
  • 204: No Content
  • 300: Multiple Choices
  • 301: Moved Permanently
  • 302: Found (temporary redirect)
  • 304: Not Modified

Failure Codes (Red) #

  • 400: Bad Request
  • 401: Unauthorized
  • 403: Forbidden
  • 404: Not Found
  • 500: Internal Server Error
  • 502: Bad Gateway
  • 503: Service Unavailable

Status Badge Colors #

  • Green: Success codes (server is up)
  • Red: Failure codes (server is down)
  • Gray: No data or unknown status

Archive and Restore #

Archiving Servers #

When to Archive:

  • Server permanently decommissioned
  • Temporarily disable monitoring
  • Clean up server list

Archive Process:

  1. Select server(s) to archive
  2. Click "Archive" button
  3. Confirm action
  4. Server moved to archived state

What Happens:

  • Historical data preserved
  • Monitoring stops immediately
  • No new notifications sent
  • Can be restored later

Restoring Servers #

Requirements:

  • Must be within plan server limits
  • Organization must have active subscription

Restore Process:

  1. Switch to "Archived" filter
  2. Select archived server(s)
  3. Click "Restore" button
  4. Monitoring resumes immediately

Performance Monitoring #

Uptime Calculation #

Method: Time-based calculation using status change logs Formula: (Total Time - Downtime) / Total Time × 100

Example:

  • Server created: January 1, 00:00
  • First failure: January 1, 12:00 (down for 1 hour)
  • Recovered: January 1, 13:00
  • Uptime: (24h - 1h) / 24h × 100 = 95.83%

Check Frequency #

Premium Plans (Basic, Pro, Enterprise):

  • 1-minute checks
  • 60-second SLA
  • High priority queue

Free Plan:

  • 5-minute checks
  • 300-second SLA
  • Standard priority queue

Performance Metrics #

Response Time: Time from check dispatch to completion Job Queue Time: Time jobs wait in queue before processing SLA Compliance: Percentage of checks completed within SLA

Bulk Operations #

Bulk Archive #

  1. Select multiple servers using checkboxes
  2. Click "Archive" in toolbar
  3. Confirm bulk action
  4. All selected servers archived simultaneously

Bulk Restore #

  1. Switch to "Archived" filter
  2. Select archived servers
  3. Click "Restore" in toolbar
  4. Servers restored if within plan limits

Bulk Delete (Permanent) #

  1. Navigate to archived servers
  2. Select servers to permanently delete
  3. Click "Delete" button
  4. Warning: This permanently removes all data

Organization Limits #

Server Limits by Plan #

Plan Limit
Free 50
Basic 200
Pro 500
Enterprise Unlimited

Checking Limits #

PHP Console:

use Albrightlabs\ServerMonitor\Models\Server;

// Check remaining servers for organization
$info = Server::getRemainingServerCount($organizationId);
echo "Limit: {$info['limit']}, Used: {$info['used']}, Remaining: {$info['remaining']}";

When Limits Reached:

  • New server creation blocked
  • Error message with upgrade link
  • Existing servers continue monitoring

Troubleshooting #

Server Not Being Monitored #

Check List:

  • [ ] Organization has active subscription
  • [ ] Server within plan limits
  • [ ] Queue workers running
  • [ ] Cron jobs configured
  • [ ] API endpoints responding

Debug Steps:

# Check server in database
php artisan tinker
>>> $server = \Albrightlabs\ServerMonitor\Models\Server::find(123);
>>> $server->organization->subscription_status;

# Check recent job logs
php artisan queue:work --once --queue=premium

Status Not Updating #

Common Causes:

  • Queue backlog
  • Worker not running
  • Cron jobs not firing
  • DNS/network issues

Investigation:

# Check queue size
php artisan queue:work --once

# Check last update
php artisan tinker
>>> $server = \Albrightlabs\ServerMonitor\Models\Server::find(123);
>>> $server->last_checked_at;

Uptime Calculation Issues #

Force Recalculation:

# Via API
curl "https://yoursite.com/api/servermonitor/calculate/server/123/YOUR_API_KEY"

# Via console
php artisan tinker
>>> $server = \Albrightlabs\ServerMonitor\Models\Server::find(123);
>>> $server->updatePercentUptime();

Best Practices #

Server Naming #

  • Use descriptive names: "Production API" vs "server1"
  • Include environment: "Staging Database" vs "Database"
  • Add location if relevant: "US East Web Server"

Endpoint Selection #

  • Monitor main application URLs, not infrastructure
  • Use HTTPS when possible
  • Choose URLs that represent service health
  • Avoid redirects when possible

Monitoring Strategy #

  • Start with critical services first
  • Monitor user-facing endpoints
  • Include both web and API endpoints
  • Consider database connectivity checks

Maintenance #

  • Regular review of server list
  • Archive decommissioned servers
  • Update endpoints when services move
  • Monitor plan usage and upgrade when needed

Next Steps #

After adding servers:

  1. Configure Notifications - Get alerted to status changes
  2. Monitor Performance - Ensure monitoring is working properly
  3. Review Database Structure - Understand data relationships

Previous: Notifications | Next: Branding