Settings

1. Notify when site is offline or not reachable

The master switch. Off by default.

The panel shows the current state with a coloured dot so it is unambiguous from across the room, rather than leaving you to read a toggle position.

It needs a primary domain

Monitoring works by requesting your application's URL, so without a primary domain there is nothing to request. If you see this warning, set the primary domain on the Domains tab first — turning the toggle on alone will not start anything.

This is the most common reason someone believes monitoring is on and hears nothing when a site goes down.

2. Advanced Settings

Collapsed by default. Two settings, both worth understanding before you change them.

Check Interval

How frequently SharkCluster pings your application.

This sets your worst-case detection time. At 60 minutes, an outage that starts just after a check goes unnoticed for an hour. At 5 minutes you find out quickly — and you also generate twelve times the requests against your own application.

For anything customer-facing, 5 or 10 minutes is the right choice. Reserve longer intervals for internal tools where an hour of downtime is genuinely tolerable.

Failure Threshold

Number of consecutive failed checks before an alert is sent.

This is your noise control, and it multiplies with the interval.

Immediate catches everything, including a single dropped request during a deploy or a momentary network blip — which is how alerts become noise people learn to ignore.

2 consecutive failures is the sensible default for most applications: it filters transient blips while still telling you within minutes.

3 suits an application known to be occasionally slow, at the cost of a later warning.

3. How alerts work

The panel explains its own behaviour, and the detail matters:

1. 1SharkCluster pings your application URL on the configured interval.
2. 2An alert is triggered after the configured number of consecutive failures.
3. 3You receive an email and an in-app notification — the bell icon in the panel.
4. 4Repeat down-alerts are suppressed for one hour to avoid spam.
5. 5If Recovery Notification is on, you are also told when the site comes back up.

The one-hour suppression is important

A site that is down for six hours generates one alert, not seventy-two. That is deliberate and good — but it means the absence of new alerts does not mean the site recovered. Check the application, or rely on the recovery notification, to know it is back.

Recovery notification

Tells you when the site returns. Worth having on: without it, an outage has no closing bracket, and you are left refreshing the site to find out whether it is still down.

4. Saving

SAVE applies the settings, confirming with Settings saved successfully or reporting Failed to save. Please try again.

Settings take effect from the next check — there is no need to restart anything.

5. What monitoring does and does not catch

Catches:

• The server being down or unreachable
• The web server not responding
• The application returning an error page
• DNS or certificate problems severe enough to break the request

Does not catch:

• A site that loads but shows wrong or stale data
• A slow site that still responds
• A broken checkout, login, or any specific feature
• A background job or queue that has stopped
• A database filling up, until it breaks the page

This is uptime monitoring, not health monitoring. For the server itself — CPU, memory, disk, failed services — use Health Alerts on the server. The two are complementary: Health Alerts tells you the server is in trouble before it goes down; this tells you the application is unreachable once it has.

6. Recommended settings

And regardless of the above: set the primary domain first, or none of it runs.

7. Common problems