Site Monitoring
Overview
Site monitoring checks a URL over HTTP or HTTPS on a schedule and records what came back: the status code, the full response-time breakdown, the SSL certificate, and optionally whether the page contains particular text.
A site monitor is not only an uptime check. The same monitor also tracks SSL certificate expiry, domain expiry, captures screenshots, and can run broken-link crawls and Lighthouse audits.
INFO
Site monitors count toward your plan's monitor limit. See Plans & Limits.
Features
- Uptime checks from your chosen location, as often as every 30 seconds on higher plans.
- Response-time breakdown — DNS lookup, connect, TLS handshake, time to first byte and total, so you can tell a slow network apart from a slow application.
- Content checks — alert when the page stops containing expected text, or starts containing text it should not.
- Any HTTP method with custom headers, POST body and user agent.
- SSL and domain expiry alerts well before anything actually expires.
- Multiple monitoring locations — up to five additional locations on paid plans.
- Screenshots of the rendered page, shown in the list and on the overview.
How to Set Up Site Monitoring
- Sign in to your Pingniner account and go to Sites.
- Click "New Site".
- Enter a Name — a friendly name for the list.
- Enter the URL to monitor, including
http://orhttps://. - Choose a Monitoring frequency. The options available depend on your plan — see Plans & Limits.
- Choose a Monitoring Location — the region checks run from.
- (Optional) Enable Lighthouse Check and pick a Lighthouse Schedule of
WeeklyorMonthly, or leave the schedule empty to run audits manually. Paid plans - (Optional) Open Advanced to configure the request — see below.
- Save. The first check runs shortly afterwards.
Advanced options
| Option | Default | Notes |
|---|---|---|
| Method | GET | GET, POST, PUT, PATCH or DELETE |
| Expected status code | 200 | Any code from 0–999. Anything else is treated as a failure. |
| Additional monitoring locations | none | Up to 5 extra locations, excluding your primary one. Paid plans |
| Timeout | 30 seconds | Total request timeout, 1–120 |
| Connect Timeout | 15 seconds | Connection phase only, 1–120 |
| POST data | empty | Raw request body |
| User agent | empty | Sent as the User-Agent header |
| Headers | empty | Any additional request headers, as key/value pairs |
| Group, Tags, Notes | empty | Organisation only — see Groups & Tags |
TIP
Monitoring an API endpoint that returns 201 or 204? Set Expected status code to match, or every successful check will be recorded as a failure.
Viewing & Managing Sites
Each site has its own sub-navigation: Overview, History, Broken Links, Lighthouse, Triggers, Alerts, Maintenance and Settings.
Overview
Current status and last checked time, plus:
- Certificate Expiration and Domain Expiration, colour-coded — amber under 30 days, red under 10.
- Domain Registration date and Nameservers.
- Monitoring Location and Retention.
- A screenshot of the rendered page.
- Uptime chart, and a response-time chart per monitoring location.
Edit
All the creation fields can be changed later from Settings, including the URL. Changing the URL does not reset history.
History
One row per check, with:
| Column | Meaning |
|---|---|
| Timestamp | When the check ran |
| HTTP status code | What the server returned |
| DNS lookup | Time spent resolving the hostname |
| Connect | Time to establish the TCP connection |
| TLS handshake | Time to negotiate SSL/TLS |
| TTFB | Time to first byte |
| Latency | Total request time |
| Online | Whether the check passed |
| Location | Which location ran it |
All times are in milliseconds. History retention depends on your plan.
Triggers
Sites come with a fixed catalogue of triggers. You can edit and enable or disable them, but you cannot create or delete them.
| Trigger | Value field | Default | Active by default |
|---|---|---|---|
Offline | — | 3 occurrences, impact Down | Yes |
Response time | Threshold (ms) | >= 4000, 5 occurrences, impact Degraded | Yes |
HTTP Status Code | Expected HTTP Status Code | — | No |
Contains | Keyword(s) in the source code | 3 occurrences, impact Degraded | No |
Does not contain | Keyword(s) in the source code | 3 occurrences, impact Degraded | No |
Certificate expires | Days | 10 days, 1 occurrence | Yes for https:// URLs |
Domain expires | Days | 10 days, 1 occurrence | No |
Median response time | Deviation threshold (%) | >= 100% | Yes on new monitors Paid plans |
Each trigger also has Contacts, Occurrences (1–50), Repeating notifications and an Active toggle. See Triggers & Incidents.
INFO
Certificate expires is enabled automatically when the URL starts with https://, and left disabled otherwise. If you switch a site from HTTP to HTTPS later, enable it yourself.
TIP
Contains is the trigger that catches the failure uptime checks miss: a page that returns 200 OK while rendering an error, an empty cart or a stale maintenance notice. Point it at a string that only appears when the page is genuinely working.
Alerts
Every incident raised for this site, with its trigger, start and end times, and when the last notification was sent.
Maintenance
Suppress triggers and notifications for a planned window. Checks continue and data is still recorded. See Maintenance Periods.
Best Practices
- Monitor the URL your users actually hit, redirects included, rather than an internal health-check path that can succeed while the site is broken.
- Add a
Containstrigger on anything transactional. Status codes lie. - Leave certificate expiry at 10 days minimum. Automated renewal usually happens at 30 days, so an alert at 10 means renewal has genuinely failed.
- Use additional locations for performance, not uptime. They tell you whether slowness is regional; a single location is enough to know the site is down.
- Raise occurrences rather than muting a noisy monitor. A site that fails one check in fifty is usually a network blip, not an outage.
