A site can return HTTP 200 while its contact form is broken, its certificate is near expiry or its latest deployment serves a blank page in one region. Synthetic monitoring closes part of that gap by repeatedly exercising a small, safe journey from outside the application and recording what a visitor would actually experience.
Begin with one public landing page and the most valuable journey: a portfolio contact path, a client login page or a read-only API endpoint. Check status, expected content, redirect destination, TLS validity and an upper bound on response time. Browser-based probes can also catch JavaScript errors and missing assets, but they cost more and need resilient selectors. A layered monitor uses a cheap HTTP check frequently and a smaller browser journey less often.
| Signal | What it tells you | Common false conclusion |
|---|---|---|
| DNS and TLS | Name resolution and certificate validity from the probe location | “The whole site is down” after one resolver issue |
| HTTP status and content | Reachability plus a basic expected response | “The page works” because a generic 200 was returned |
| Browser journey | Critical rendering and interaction path | “The backend is healthy” from a UI-only success |
| Regional agreement | Whether symptoms repeat across independent vantage points | “No incident” when only the nearest region passed |
Show the last successful check, the last failure, probe location, check version and deployment revision together. Keep latency distributions separate from uptime, and make missing data visually distinct from healthy data. An empty chart is not a green chart.
For a low-traffic portfolio, a five-minute check may be enough; the right interval depends on how quickly you need detection and what the probe costs. A single failure can trigger a diagnostic event, but paging should usually require repeated failure or agreement from independent regions. Add a recovery notification and suppress duplicate alerts while the incident remains open. Do not alert on every slow sample if users have no meaningful impact.
Use synthetic accounts, minimal permissions and read-only actions. Avoid submitting real contact forms repeatedly; route a test submission to an isolated sink or use a dedicated health endpoint. Never place credentials or personal data in probe URLs, screenshots or logs. Protect browser recordings because they can contain cookies or page content.
If the monitoring job runs only on the same hosting account as the site, a provider outage can silence both. Store results externally or use a monitoring service with independent execution. Set timeouts, retries and resource limits so a hanging page cannot consume an unbounded worker. Track monitor freshness: a delayed or missing probe should be reported as monitoring degradation, not inferred uptime.
Start with an HTTP checker, a browser journey for one critical path, a compact time-series store and alerts that link to diagnostic evidence. Record response code, timing, region, assertion outcome and deployment identifier. Use the probe to open an incident, not to automatically restart or mutate production until false-positive behavior is understood. Pair it with internal metrics: synthetic monitoring answers “does this journey work from here now?” while application telemetry helps explain why.
For broader alert design, see observability on a budget and incident postmortems for solo developers.
Useful synthetic monitoring checks a meaningful customer outcome, runs from an independent vantage point and presents evidence with freshness and deployment context. Keep probes safe, distinguish one-off noise from sustained impact and make a missing check visibly different from a successful one.