Witch

Getting started

Witch starts with a public website URL. Free workspaces receive HTTP/TLS monitoring; paid plans add Chromium rendering, visual baselines, alerts, reports, and other browser-level signals.

What you can monitor

Publicly reachable HTTP or HTTPS websites. Witch rejects private/internal destinations as part of its SSRF protections.

What Witch does not need

Witch does not use your dashboard cookies when it monitors a site. Monitoring runs separately from your signed-in Witch session.

Add a site

Open Sites and choose Add site. Enter the public URL you want Witch to watch.

Wait for the first checks

Witch creates HTTP monitoring immediately. On plans with browser monitoring, desktop and mobile Chromium checks are also queued and initial visual baselines are created.

Review the site

Open the site detail page to inspect live status, telemetry, visual baselines, surveillance rules, incidents, check history, and site-specific settings.

Run a manual check after a deploy

Use Run check when you want fresh evidence immediately. Manual checks have a 60-second cooldown to prevent accidental request storms.

How Witch works

Witch separates basic reachability from what a real browser actually receives. A site can return HTTP 200 and still be broken for users.

1. Connection

HTTP checks measure reachability, response status, latency, redirects, TLS validity, and related endpoint health.

2. Browser render

On supported plans, Chromium renders the site in isolated browser contexts and collects browser, DOM, asset, and visual evidence.

3. Incident

Deterministic monitoring signals are classified into incidents. Visual evidence and AI analysis can be attached after an incident exists.

The scheduler queues due monitors with jitter, and the worker processes HTTP checks, browser checks, AI analysis, alert delivery, monthly reports, and screenshot-retention jobs. Monitoring state and incident history are stored per workspace.

Sites

A site is the main monitored object inside a Witch workspace.

The Sites view shows each monitored service, its current state, latest telemetry, and open incident count. Filters can narrow the list to healthy services, issues, or paused services.

Pause a site

Pausing stops scheduled surveillance for that site without deleting its history. Plan enforcement can also pause sites that exceed the current site allowance after a downgrade.

Delete a site

Site deletion is destructive. Surveillance and alerts stop and the site's related data is removed according to the application's cascading data rules.

Each site detail page contains six areas: Overview, Visual Baselines, Surveillance, Incidents, Check Log, and Settings.

HTTP & TLS monitoring

HTTP monitoring is available on every plan, including Free.

HTTP checks are the base availability layer. They record whether the request completed successfully, response status, latency, final URL, resolved IP, TLS validity, TLS expiry where available, and error information when a check fails.

Status is not based on one cosmetic signal

Witch uses confirmed monitoring state rather than treating every transient request as a permanent outage. Recovery also requires healthy checks before an incident closes. The exact confirmation values are deployment configuration, so the UI should be treated as the source of truth for the current incident state.

Plan minimum HTTP intervals are listed in Plans & limits. The Free plan checks no more frequently than every 30 minutes; paid plans allow 5-minute HTTP intervals.

Browser & visual monitoring

Freelancer and higher plans can render pages in Chromium, capture desktop/mobile views, compare them with accepted baselines, and detect meaningful browser-side failures.

Desktop and mobile

Witch can maintain separate desktop and mobile browser monitoring so responsive failures do not disappear inside a desktop-only check.

Accepted baseline

A baseline is the approved visual state used for comparison. Accepting a new baseline changes the reference image without deleting the historical evidence that led to the change.

Visual sensitivity

Site settings offer Low, Medium, and High visual sensitivity. Medium is the default. Low tolerates more minor pixel/font movement; High is intended for stricter comparison.

Noise controls

Visual monitoring can exclude or clean common sources of non-product noise. Current controls include cookie-consent banners, chat widgets, marketing popups, ad containers, sticky promotional bars, custom ignore selectors, clean-capture mode, automatic consent dismissal, and an emulated light/dark/default color scheme.

Default noise behavior

Cookie-consent banners and chat widgets are ignored by default. Marketing popups, ads, sticky promotional bars, clean capture, and automatic consent dismissal are opt-in unless changed in site settings.

Element surveillance

Browser-enabled plans can add element monitors using a CSS selector, expected text, or both. These are useful for critical controls such as checkout buttons, login forms, booking actions, and other elements that must remain present.

Incidents

Incidents collect confirmed failures and the evidence needed to understand what changed.

Witch currently surfaces incident types such as HTTP failures or slow responses, page structure/content changes, JavaScript errors, visible asset failures, element failures, and visual regressions. The exact title reflects the deterministic signal that opened the incident.

Lifecycle

Incidents can be Open, Acknowledged, Resolved, or Ignored. Resolved incidents remain part of history; ignored incidents are excluded from public status-page uptime history.

Evidence

Incident detail can include timing, failed resources, browser/DOM signals, screenshots, visual baseline/current frames, and visual differences where that evidence exists.

Paid plans can receive AI incident analysis after a deterministic incident has been opened. AI is supplementary: it does not replace the underlying monitoring signal that created the incident.

Alerts & notifications

Freelancer and higher plans can deliver incident and recovery notifications.

Workspace administrators can enable incident alerts, recovery alerts, monthly digest reports, and a minimum alert severity. Delivery destinations can include email addresses and Discord webhooks.

Email delivery

Witch supports email delivery through the configured production email provider. Public status-page subscriptions also use email confirmation before a subscriber starts receiving updates.

When an incident recovers, Witch can send a separate recovery notification. Alert availability follows the workspace's effective plan.

Public status pages

A workspace can publish selected monitored sites on a public status portal.

In Settings → Status Page, administrators can enable the public page, choose a unique slug, set a custom headline/subheadline, allow visitor subscriptions, and show or hide 90-day uptime history bars.

Individual sites must also have Show on public status page enabled before they appear publicly.

90-day history

Public uptime history is built from real HTTP check data and incident periods. Unknown/no-data days are not silently presented as healthy.

Stale monitoring

A stale public service is shown as delayed/unknown rather than falsely operational. Paused and unknown services are not treated as healthy.

Visitor subscriptions are available when public subscriptions are enabled and the workspace plan supports email alerts. Subscribers must confirm their email and receive unsubscribe links in subsequent status notifications.

Reports

Freelancer and higher plans receive monthly, client-ready monitoring reports.

Reports are generated automatically for eligible sites for the previous calendar month. Current report metrics include HTTP uptime, number of HTTP checks, detected incidents, resolved incidents, average response time, and the site's current status at generation time.

Reports can be opened from Reports and are designed to be printed or saved as PDF from the browser. If monthly report emails are enabled and a billing email is configured, Witch can email the generated report link.

Team & workspaces

A Witch account can belong to one or more isolated workspaces, subject to plan limits.

Workspace data is tenant-isolated. Switching workspace changes the active organization context; sites, incidents, reports, settings, and team membership are scoped to that workspace.

Role	Access
Owner	Full workspace control, including ownership transfer and administrative operations.
Admin	Administrative access including team and workspace settings. Owners and Admins can invite members.
Member	Writable workspace access for monitoring workflows, without administrative team privileges.
Viewer	Read-only access.

Invitations

Team invitations expire after 7 days. An invite is tied to the email address it was sent to and cannot be accepted by a different account email.

Plans & limits

These limits are taken from Witch's current plan configuration.

Plan	Price	Sites	HTTP	Browser	History	Members	Workspaces	API keys
Free	$0/mo	1	30 min	No	7 days	1	1	1
Freelancer	$9/mo	5	5 min	15 min	30 days	2	2	5
Agency	$24/mo	25	5 min	15 min	90 days	10	5	20
Agency Pro	$49/mo	75	5 min	5 min	180 days	25	10	50

Browser monitoring, visual monitoring, email/Discord alerts, and reports start on Freelancer. Agency and Agency Pro enable advanced reporting; Agency Pro also enables priority checks. Subscription entitlements currently remain active for active, trialing, and past_due subscription states.

What happens after a downgrade

Witch applies the new plan limits. Sites above the site allowance can be paused, browser monitors can be disabled if the new plan does not include them, and monitor intervals are raised to the minimum allowed by the new plan.

API keys

Workspace administrators can create and revoke scoped Witch API keys from Settings.

API key allowances are plan-limited. A newly created secret is shown at creation time and can be copied then. Revocation invalidates the stored key.

Current public API status

Witch does not expose a general public HTTP API in this release. API keys are provisioned by the product, but this documentation does not invent endpoints that do not currently exist.

Security & privacy

Witch's monitoring and workspace model includes several protections that matter when reading evidence.

Tenant isolation

Workspace-owned queries are scoped by organization. Authenticated media routes verify access before serving screenshots.

Private targets rejected

Monitoring accepts public HTTP(S) destinations. Redirects are revalidated, and private/internal network targets are rejected.

Separate browser context

Browser monitoring does not reuse your Witch dashboard cookies. Checks run independently in isolated Chromium contexts.

Screenshots are not public files

Stored monitoring images are served through application routes rather than exposed as a public storage directory.

Public status pages are intentionally public when enabled. Review which sites are marked visible before publishing a status portal.

Troubleshooting

Common product-level checks before treating something as a monitoring failure.

The site is online but Witch opened an incident

This can be correct. Witch can detect browser-side breakage, missing controls, JavaScript failures, failed visible assets, content/DOM changes, or visual regressions while the origin still returns HTTP 200.

A visual change is expected

Review the Visual Baselines tab. If the new render is the intended design, accept the current snapshot as the new baseline rather than deleting historical evidence.

Cookie banners or chat widgets keep changing

Use the visual-noise controls in the site's Settings tab. Cookie-consent and chat-widget masking are already enabled by default unless changed.

A check looks delayed

Witch explicitly marks stale monitoring rather than silently calling it healthy. Run a manual check and review the Check Log for the latest completed telemetry.

I cannot enable browser monitoring

Browser and visual monitoring require Freelancer or above. Free workspaces use HTTP/TLS monitoring only.

I am not receiving alerts

Confirm the workspace is on a plan with alerts, the relevant incident/recovery trigger is enabled, the minimum severity allows the incident, and at least one email or Discord destination is configured.

FAQ

How is Witch different from a basic uptime monitor?

A basic uptime monitor primarily asks whether an endpoint answers. Witch can also render the page in Chromium, inspect browser/DOM/asset signals, maintain visual baselines, and open incidents when the user-facing page changes or breaks.

Does Witch crawl my entire website?

No. A Witch site is a monitored target URL with scheduled checks. The browser opens the configured target for its checks; it is not a general-purpose site crawler.

Will a green HTTP result always mean the page works?

No. HTTP reachability and browser correctness are separate signals. That distinction is the core reason browser and visual monitoring exist.

Can I monitor mobile separately?

Yes on browser-enabled plans. Witch supports separate desktop and mobile Chromium monitoring and visual baselines.

Can I publish service health to customers?

Yes. Enable the workspace status page, choose a public slug, and mark the individual services you want visible.

Can visitors subscribe to public status updates?

Yes when public subscriptions are enabled, email delivery is available, and the workspace plan includes alerts. Subscriptions require email confirmation.

Does AI decide whether my site is broken?

No. Deterministic monitoring opens the incident first. AI analysis, when available, is attached afterward to help explain the incident.

Documentation accuracy

This guide documents behavior that exists in the current Witch application. It deliberately does not document unshipped endpoints or features as if they were available.