Proactive health alerts
before things break
Threshold-based alerting on four server metrics — off by default, one toggle turns it on. Application uptime monitoring pings your URLs. Nothing fails silently.
4
Monitored metrics
5
Check intervals
1hr
Alert suppression
0
Silent failures
Four metrics, four thresholds
Each metric has a configurable threshold with sensible defaults. The disk threshold is recommended at 80% — a full disk fails silently in ways that mimic unrelated bugs.
CPU Usage
Default 90% — fires on sustained load above threshold
RAM Usage
Default 90% — Linux counts disk cache as used memory
Disk Usage
Default 90%, recommended 80% — most valuable change you can make
Failed Services
Default 1 — intentionally strict, a single crash is worth knowing
Application uptime monitoring
SharkCluster pings your application URL on your chosen interval. An alert is triggered after the configured number of consecutive failures. You receive an email and an in-app notification.
- Check interval: 5, 10, 15, 30, or 60 minutes
- Failure threshold: 1st failure, 2 consecutive, or 3 consecutive
- Recovery notification — tells you when the site comes back up
- Repeat down-alerts suppressed for one hour to avoid spam
- Requires a primary domain to be set first
URL
https://api.sharkcluster.com
Interval
5 min
Threshold
2 consecutive
Alert routing & triage
Alerts surface in multiple places: the Monitoring dashboard with graphs, the Failed Services panel, and the underlying CPU/memory/disk graphs. A built-in triage table tells you what to check when each metric fires.
- Email and in-app bell notification
- Two-tier permissions: view thresholds vs manage thresholds
- Recent Alerts log with metric, value, threshold, severity, and time
- Value-vs-threshold shown side by side — near-miss vs real breach
Built-in tuning guidance
The panel doesn't just expose the threshold — it tells you what to set it to and why. Alert-fatigue guidance is included: don't set thresholds so low they fire constantly — an ignored alert is worse than no alert.
- Disk at 80% — the single most valuable change on this page
- RAM alerts need interpretation — check swap, not raw percentage
- Failed-services threshold of 1 is intentionally strict
- Alert-fatigue guidance: don't set thresholds too low
Recommended 80% — not 90%
Default 90%
Strict — 1 crash fires
Provider maintenance notifications
Cloud providers schedule maintenance windows that can affect your servers — reboots, network blips, or temporary unavailability. The panel surfaces these scheduled events so you can plan around them rather than discovering them mid-incident.
- Scheduled maintenance events surfaced in the panel
- Affected servers identified before the window
- Email and in-app notification ahead of time
- Planned vs unplanned events distinguished
Metrics history that tells a story
Historical graphs aren't just for the last hour. Metrics history is retained so you can look back at trends — spot a slow memory leak, correlate a spike with a deploy, or confirm a problem is resolved and not just quiet.
CPU, memory, disk, and network history retained
Selectable time windows for trend analysis
Correlate spikes with deployments or maintenance
Everything around your server
Pair monitoring with the tools that keep your applications fast, secure, and resilient.
SharkCluster monitors CPU usage, RAM usage, disk usage, and failed services with configurable thresholds. Application-level uptime monitoring pings your URLs on your chosen interval.
Health alerts fire when a metric exceeds its configured threshold. You receive an email and in-app notification. Repeat down-alerts are suppressed for one hour to avoid spam.
SharkCluster recommends setting the disk threshold at 80%, not the 90% default. A full disk fails silently in ways that mimic unrelated bugs — broken uploads, stalled logs, database write refusals.
Ready to take control
of your hosting?
Deploy servers, run self-hosted business apps, and keep your data on your own VPS — with a dedicated DevOps manager by your side.