Alerts and alert timing

Alert channels

Watchfox supports multiple alert channels such as email, Slack, webhook, Microsoft Teams, Discord, and Google Chat. Configure at least one channel before relying on a project for production monitoring.

• Use email for simple individual or small-team setup.
• Email channels support one recipient per channel. Create one email channel per recipient when multiple people should receive alerts.
• Use chat channels for team visibility.
• Use webhooks for custom automation and high-volume integrations.
• Email repeat reminders are subject to fair-use limits to protect deliverability and prevent accidental inbox floods.
• Send a test alert after creating or changing a channel.

First alert delay

First alert delay lets Watchfox wait before sending the first DOWN alert. This helps reduce noise from very short transient failures.

• Use a short delay for critical production pages.
• Use a longer delay for noisy targets, slow third-party services, or low-priority checks.
• Use no delay only when immediate notification is worth the extra noise.

Repeat reminders

Repeat reminders keep the team informed while an issue remains unresolved. Use them carefully so long incidents stay visible without flooding channels.

• Turn reminders on for important production services.
• Keep reminder intervals high enough to avoid alert fatigue.
• Turn reminders off when another incident workflow already handles escalation.
• Email repeat reminders use fair-use limits by workspace and recipient. If the limit is reached, additional email reminders are suppressed and recorded in the delivery audit.
• First DOWN alerts and recovery alerts are prioritized over repeat reminders.
• Slack, webhook, Teams, Discord, and Google Chat channels are recommended for higher-volume operational workflows.

Recovery alerts

Recovery alerts notify the team when a service returns to UP. For operational clarity, recovery alerts should be enabled for production monitors unless you have a specific reason to suppress them.

After a recovery, a later new DOWN state should be treated as a new incident path. Do not assume an old recovered incident should suppress future alerts.

Maintenance mute

Use one-time maintenance windows for expected downtime. Planned maintenance should suppress unnecessary alert noise while still keeping the operational history understandable.

• Create a one-time maintenance window before deployments, migrations, DNS changes, or known provider work.
• Checks can continue to be recorded during maintenance, but alert delivery is muted while the window is active.
• Recurring maintenance is not supported at launch. Create a separate one-time window for each planned work period.
• Use status page maintenance messaging when customers should know about planned work.
• Review maintenance timing if alerts are muted longer than expected.

Paused monitor behavior

Paused or disabled monitors should not create surprise alerts. If an expected alert does not arrive, first check whether the monitor is enabled.

• Existing history can still appear in dashboards and reports.
• Resume a paused monitor only after checking target, interval, alert channel, and alert timing.
• Use pause for temporary silence, not as a replacement for archiving old projects.

Archived project behavior

Archived projects are read-only operational history. They should not create new monitors, new status pages, new notification channels, or surprise runtime activity.

• Create active monitors only in active projects.
• Keep archived projects for review and historical context.
• If monitoring should resume, unarchive where supported or create a new active project.