Uptime monitoring
Uptime (/telemetry/uptime, a tab of Telemetry) runs HTTP(S) checks of your apps from Shield360’s servers. Your app does not need the SDK for this: Shield360 requests the address the way a visitor would.
Add a monitor
Section titled “Add a monitor”Choose New monitor and set:
| Setting | Meaning |
|---|---|
| Address | A public http:// or https:// URL, such as https://shop.example.com/health |
| Service | Optional. The app’s service name, so its uptime alerts join the app’s other incidents |
| Method | GET, or HEAD when the body does not matter |
| Check every | 1, 5 or 15 minutes |
| Timeout | 1 to 30 seconds |
| Expected status | A code or range, such as 200-299 or 200,204. Redirects are followed (up to five) unless a redirect status is expected |
| Body contains | Optional text the page must contain (GET only). The body is searched and never stored |
| Down after | Failed checks in a row before the monitor is down (2 by default, so one blip does not page anyone) |
| Alert severity | The severity of its uptime.down alert |
| Check the TLS certificate | An invalid or expired certificate fails the check; a certificate that expires within the days you set raises a warning |
What you see
Section titled “What you see”- Each monitor’s status (up, down, not checked yet), uptime over 24 hours and 30 days, last response time and last check.
- For one monitor: uptime and average response time over 24 hours, 7 days or 30 days, failed checks on the same axis, certificate expiry, and the last 20 checks with their status code and reason.
Check results are kept for 14 days and daily totals for 400 days.
Alerts and incidents
Section titled “Alerts and incidents”| Alert kind | When |
|---|---|
uptime.down | The monitor failed its checks the set number of times in a row. It stays open until the next good check resolves it. |
uptime.tls_expiring | The certificate expires within the days you set (critical within 3 days). Once a day per certificate. |
Route them to channels with an event alert rule, or open incidents with an escalation policy whose kinds include uptime.down. When the monitor recovers, the alert resolves and, if every alert in it has resolved, so does the incident.
Safety
Section titled “Safety”Uptime checks only reach public addresses. Shield360 refuses, when you save a monitor and again on every check and every redirect:
- private, loopback, link-local and cloud metadata addresses (for example
10.0.0.0/8,127.0.0.1,169.254.169.254,::1), and names such aslocalhost,*.internaland*.local; - a host name that resolves to any such address. The connection is made to the address that was checked, so a name cannot point somewhere else between the check and the connection;
- ports below 1024 other than 80 and 443, and addresses with a user name or password.
Checks run from Shield360’s own servers. Monitoring from several regions and a public status page are not offered.
Limits
Section titled “Limits”| Plan | Monitors per organization |
|---|---|
| Free | 1 |
| Team | 10 |
| Business | 50 |
Self-hosted deployments allow up to 200 per organization (UPTIME_MAX_MONITORS). One organization runs at most 30 checks per 30-second tick (UPTIME_MAX_PER_ORG), three at a time. UPTIME_SCHEDULE=off turns checks off on a deployment.