Security & Privacy#

Server Pulse is designed with security and privacy as core priorities. The collector only reads system-level metrics — it never accesses application data, user data, files, databases, or logs. Communication is encrypted and authenticated using industry-standard protocols.

Available on: Business plans

What data is collected#

Server Pulse collects only system-level metrics necessary for performance monitoring. It does not access or transmit any application or user data.

Collected (system metrics only)#

• CPU usage percentage and core count
• Memory and swap usage (total, used, percentage)
• Disk usage per mount (mountpoint, device, filesystem type, total/free/used/percentage)
• Load averages (1, 5, 15 minute)
• Network throughput (bytes received/sent per second)
• System information: OS name, platform, platform version, kernel version, architecture, virtualization type, CPU model name
• Server hostname and uptime

NOT collected#

• File contents, application code, or source files
• Database contents or credentials
• Environment variables or configuration files
• User data, session data, or authentication tokens
• Process lists, command history, or running application details
• Log files or application output
• Network traffic content or packet data

Authentication#

Every Server Pulse instance uses a unique API token for secure authentication.

• Each token follows the format pw_tok_ followed by a UUID
• The collector authenticates via Bearer token in the HTTP Authorization header
• Tokens are validated server-side on every request
• Invalid or missing tokens are rejected with a 401 Unauthorized response
• Each token is tied to a specific site — tokens cannot be reused across sites

Token management#

Manage your API tokens securely to maintain system integrity.

• Tokens are generated automatically when you enable Server Pulse
• You can regenerate a token at any time from the Server Pulse dashboard
• Regenerating a token immediately invalidates the old one
• After regenerating, update the collector configuration on your server and restart the service
• Treat your API token like a password — do not share it or commit it to version control

Transport security#

All communication between the collector and Pulsewise uses encrypted channels.

• All communication uses HTTPS (TLS encrypted)
• The collector sends data to POST /api/collect over HTTPS only
• No data is transmitted in plaintext
• TLS certificates are validated to prevent man-in-the-middle attacks

Rate limiting#

The API endpoint implements rate limiting to prevent abuse and ensure fair resource usage.

• Rate limit: 60 requests per minute per token
• Under normal operation, the collector sends well within this limit
• Exceeding the rate limit returns a 429 Too Many Requests response

Data retention#

Metric reports are automatically pruned to maintain system performance and data hygiene.

• Metric reports are retained for 30 days
• An automated daily job prunes reports older than 30 days
• After deletion, historical metric data cannot be recovered
• Active threshold evaluations and alert state are maintained independently of report history

Server-side validation#

Every incoming report is validated against a strict schema to ensure data integrity.

• All fields are type-checked and range-validated
• Percentages must be 0–100
• Core counts must be positive integers
• Invalid payloads are rejected with a 422 Unprocessable Entity response
• Reports are stored in a database transaction to ensure consistency

Access control#

Server Pulse enforces strict access controls at multiple levels.

• Server Pulse is available on Business plans only
• Only organization members with permission to view the site can access the Server Pulse dashboard
• API access requires a valid Bearer token — there is no anonymous access
• Sites that are deactivated automatically reject collector reports

Virtual filesystem filtering#

When calculating disk usage alerts, Pulsewise automatically excludes virtual filesystems to prevent false alerts.

Excluded filesystems: devfs, tmpfs, procfs, sysfs, devtmpfs, overlay

This filtering prevents alerts from non-physical storage mounts that don't represent actual disk capacity.

Best practices#

Follow these recommendations to maximize the security of your Server Pulse deployment:

• Regenerate tokens periodically or if you suspect a token has been compromised
• Restrict outbound network access on your server to only allow HTTPS to pulsewise.app if possible
• Monitor the collector service status to ensure it stays running
• Review alert thresholds on the Alerts & Thresholds page to fine-tune sensitivity for your environment
• Keep the collector updated to the latest version for security patches and improvements