How Monitoring Works — UpMonix Technical Overview

What UpMonix monitors

Website uptime monitoring

Live

HTTP/HTTPS availability checks with failure detection.

Monitoring frequency by plan

Plan	Minimum check interval
Free	5 minutes
Starter	5 minutes
Business	1 minutes
Agency	1 minutes

Individual monitors can be configured at or above your plan minimum interval.

Failure detection

UpMonix can raise an incident when checks detect conditions including:

DNS resolution failure
Connection timeout
TLS or SSL error
Invalid or expired certificate
Unexpected HTTP status code
HTTP 500-series response
Missing expected page content or keyword
Detected hosting suspension page
Slow response beyond threshold
Invalid API response body or status

Failure confirmation

Before opening an incident, UpMonix applies confirmation logic to reduce false positives:

Default consecutive failures before incident: 3
Default recovery confirmations before closure: 2
Check timeout: 30 seconds
Monitoring from: Single external location

Multi-location confirmation is not currently enabled on this platform.

Incident lifecycle

Scheduled Check
Failure Detected
Confirmation Check
Incident Opened
Alerts Sent
Continued Monitoring
Recovery Confirmed
Recovery Notice
Incident History

False-positive prevention

Configurable consecutive failure threshold before opening an incident (default: 3 failures)
Configurable recovery confirmation count before closing an incident (default: 2 successes)
Confirmation recheck after initial failure detection
Maintenance windows to suppress alerts during planned work
Alert deduplication to avoid repeated notifications for the same incident

Alert delivery

Notification delivery retries: up to 3 attempts with intervals of 60,300,900.

API / Health endpoint monitoring

For applications that expose a JSON health URL (commonly /health), use an API / Health monitor instead of a basic website or port check. UpMonix validates HTTP status, response time, and up to five JSON fields — including nested paths such as checks.database.

Example health response

{
  "status": "healthy",
  "checks": {
    "php": true,
    "database": true,
    "env_loaded": true,
    "build": "v2"
  }
}

Typical JSON assertions

JSON key	Expected
`status`	`healthy`
`checks.php`	`true`
`checks.database`	`true`
`checks.env_loaded`	`true`
`checks.build`	`v2`

Use the string true or false to match JSON booleans.

Protected health endpoints

If your health URL requires authentication, configure an API access code when creating or editing the monitor. UpMonix can send it as:

Bearer token — Authorization: Bearer {code}
Custom header — e.g. X-API-Key: {code}
Query parameter — e.g. ?api_key={code}

Use a dedicated read-only monitoring credential. The code is stored securely with the monitor and is not displayed after save.

Setup steps

Go to Monitors → Add Monitor → API / Health (paid plans).
Enter the health URL and optional API access code.
Set expected HTTP status (usually 200) and your JSON assertions.
Route alerts through your notification channels as usual.

Port checks confirm a service accepts connections; API / Health confirms the application reports itself as healthy. Use both where appropriate.

Data and history

Check results, incident timelines and uptime summaries are stored according to your plan data retention period. See pricing for retention by plan. Weekly email reports are available on all plans.

Limitations

No monitoring system can guarantee detection of every possible fault.
Third-party notification providers (email, SMS, messaging apps) can experience delays outside our control.
A successful basic HTTP check does not always prove your full business workflow is functioning.
For critical workflows, use content checks or API validation in addition to availability monitoring.