Set up Watchfox for an agency or freelancer

When to use this guide#

Use this structure when you manage multiple client websites or several independent service groups and need clean reporting and communication for each one.

Recommended structure#

• Workspace: your agency, freelance business, or operating team.
• Project: one client, product, website group, or reporting boundary.
• Monitor: one specific operational question, such as whether a website responds, contains required text, has a valid certificate, or received a scheduled heartbeat.
• Status page: a customer-safe communication surface for one project.
• Report: evidence of health, incidents, and ongoing monitoring value for one project and period.

Create client projects#

1. Open Manage workspace from the left sidebar.
2. Create one project per client or clearly independent service group.
3. Use customer-readable project names.
4. Avoid mixing unrelated clients in one project just to reduce the project count; separation is part of the reporting and authorization model.

Add the first monitor set#

For a typical maintained website, start with:

• Uptime for the public homepage or a business-critical endpoint.
• Keyword only for a specific server-rendered text requirement.
• TLS for certificate validity and expiry.
• Domain for domain expiry awareness.
• Heartbeat for backups, imports, feeds, billing jobs, or other scheduled work.
• Sitemap when the sitemap itself and its listed URLs are part of the maintenance service.

Do not create duplicate monitors that answer the same question. More monitors are useful only when they represent separate customer outcomes.

Configure alert ownership#

• Send operational alerts to the people who can act on them.
• Prefer team chat or webhooks for higher-volume operational flows.
• Use email for simple setup or individual recipients.
• Test every new or changed channel.
• Review first alert delay, repeat reminders, recovery alerts, and maintenance windows before declaring the project production-ready.

Prepare client communication#

• Use public-safe component names such as Website, API, Checkout, or Client portal.
• Keep internal IDs, raw errors, private URLs, tokens, and engineering-only wording out of public status pages.
• Use incident updates for customer-facing context rather than exposing raw monitor evidence.
• Review a status page anonymously before sharing it.

Prepare reports#

• Confirm the selected project and report period before downloading or sending a report.
• Use branding and scheduled delivery only where the current plan allows it.
• Explain that Uptime and Keyword monitors drive web uptime metrics; TLS, Domain, Heartbeat, and Sitemap remain visible as operational monitor states but are not folded into web uptime percentages.

Before onboarding the client#

• All production monitors have at least one real result.
• Alert channels were tested.
• Labels and status page components are customer-readable.
• Planned maintenance ownership is clear.
• Report recipients and status subscribers are intentional.
• The client knows which surface to use for operational status and which contact to use for support.