Uptime Monitoring
SiteBrief checks your site every 1–5 minutes, 24/7. The moment it goes down you get an alert — and another when it recovers.
How it works
At each check interval, SiteBrief makes an HTTP or HTTPS request to your site's URL from our primary monitoring server. We measure the response time and check the HTTP status code. If the site returns a non-success status code or fails to respond within the timeout window, we flag it as down and send alerts.
When a site goes down, we continue checking. As soon as it responds normally again we mark it upand send a recovery alert.
| Status | Meaning | What triggers it |
|---|---|---|
| 🟢 Up | Site is responding normally | HTTP 200–399 within timeout |
| 🔴 Down | Site is not responding | HTTP 400+, timeout, connection refused, DNS failure |
| 🟡 Degraded | Responding slowly | Response time exceeds threshold set in settings |
What counts as 'down'
A site is marked down when any of the following happen:
- HTTP 4xx / 5xx — the server responded but with an error code (404, 500, 503, etc.)
- Connection timeout — the server didn't respond within 30 seconds
- Connection refused — the port is closed or the server actively rejected the connection
- DNS resolution failure — the domain doesn't resolve to any IP address
- SSL/TLS error — the certificate is invalid, expired, or the handshake failed
- Keyword not found — if keyword monitoring is enabled and the text is missing from the response
Check intervals
| Plan | Interval | Checks per day per site |
|---|---|---|
| Free | Every 5 minutes | 288 |
| Starter | Every 5 minutes | 288 |
| Agency | Every 1 minute | 1,440 |
| Agency Pro | Every 30 seconds | 2,880 |
Uptime percentage
The uptime percentage shown in the dashboard is calculated over the last 7 days by default. You can view 30-day and 90-day uptime in the site detail charts.
Formula: (total checks − failed checks) / total checks × 100
A single failed check in a 5-minute interval window counts as 5 minutes of downtime. For example, 1 failed check out of 288 daily checks = 99.65% uptime for that day.
Response time tracking
Every successful check records the time from sending the HTTP request to receiving the first byte of the response. This is shown in:
- The Recent checks table on the site detail page
- The Response time chart (30-day history with 7/30/90 day selector)
You can set a response time threshold in settings. If a check exceeds this threshold (e.g. 3000 ms), the site status changes to degraded and an alert is sent.
Dual confirmation
When dual confirmation is enabled, SiteBrief requires two consecutive failed checks before sending a down alert. This eliminates false positives caused by brief network blips between our server and your site.
- Check 1 fails → SiteBrief immediately re-checks
- Check 2 also fails → alert is sent
- Check 2 succeeds → no alert, site is considered up
HTTP method
By default, SiteBrief makes a GET request. You can change this to HEAD or POSTin the site settings.
| Method | When to use |
|---|---|
| GET (default) | Most websites — downloads the full page to check content and keywords |
| HEAD | When you only want to check status codes and headers, not download the body (faster, but keyword monitoring won't work) |
| POST | API endpoints that require a POST request — set a JSON or form body in the Request body field |
Environments
Each site can be tagged as Production, Staging, or Development. This is for your organisation only — it affects how the site is labeled in the dashboard and in client reports. Monitoring behavior is identical across environments.
Pausing monitoring
You can pause monitoring for a site until a specific date and time. While paused, no checks run and no alerts are sent. Use this during planned maintenance windows or deployments.