Configure Monitors
In this step, you define the endpoint checks shown on your status page.
Fields in the wizard
| Field | Description |
|---|---|
| Name | Display name shown on the status page |
| Target | URL (https://...) for HTTP methods, or host:port for TCP_PING |
| Method | GET, POST, HEAD, or TCP_PING |
| Expected Status | Expected HTTP status code for HTTP checks |
The wizard also includes a Test Endpoint action so you can validate checks before deploying.
Check proxy
A check proxy routes a monitor request through another endpoint. It is needed when the monitored site runs on Cloudflare in the same zone as your status page, because a direct check from that zone can bypass the site's Worker and reach the origin instead.
Enter either an HTTPS proxy endpoint URL (https://...) or a Globalping URI
(globalping://TOKEN?...). Enable Fall back to a direct check if the proxy fails to retry the
target without the proxy when the proxied check cannot run.
The editor's test button checks from FlareWatch's infrastructure, not from the deployed worker, so a same-zone problem will not appear in a test.
How scheduling works
FlareWatch deploys one monitor worker with a single cron schedule. In the current deployment flow, checks run every 5 minutes (*/5 * * * *).
Per-monitor intervals are not configured in the wizard today. If you need different schedules, customize the deployed runtime directly.
Where results are stored
Check state/history is stored in the flarewatch-state KV namespace in your Cloudflare account. The status page worker reads that state to render current health, latency trends, and incidents.
When monitors are ready, continue to branding.