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 stringnot_contains: Check if response body does NOT contain a stringregex: Match response body against a regular expression
Supported Protocols:
https://- Recommended for productionhttp://- 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/descriptionendpoint- 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
Paid Plans (Unlimited Users) #
- 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:
- Select server(s) to archive
- Click "Archive" button
- Confirm action
- 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:
- Switch to "Archived" filter
- Select archived server(s)
- Click "Restore" button
- 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 #
- Select multiple servers using checkboxes
- Click "Archive" in toolbar
- Confirm bulk action
- All selected servers archived simultaneously
Bulk Restore #
- Switch to "Archived" filter
- Select archived servers
- Click "Restore" in toolbar
- Servers restored if within plan limits
Bulk Delete (Permanent) #
- Navigate to archived servers
- Select servers to permanently delete
- Click "Delete" button
- 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:
- Configure Notifications - Get alerted to status changes
- Monitor Performance - Ensure monitoring is working properly
- Review Database Structure - Understand data relationships
Previous: Notifications | Next: Branding