What We Monitor

This page is the honest reference for what FTStatus actually checks today. Each monitor type is mapped to what is verified, the customer impact it catches, and its lifecycle phase:

Live — the automated checker runs it on a schedule. You can create these monitors yourself and they alert without anyone in the loop.
Operator-assisted — a Faciotech operator runs the check from the dashboard on request. The data is real and stored, but creation and follow-up are handled by the support team while the native, fully-automated monitor is finished.
Planned — the type exists in the product model but is not yet a fully wired probe. It is on the roadmap, not something to rely on today.

We keep this list deliberately conservative. If a capability is not listed as Live, do not assume it runs unattended.

Live monitor types

These run on the automated checker and are part of the self-serve product.

HTTP / HTTPS

What is checked: Sends an HTTP request to a URL and validates the response status code, headers, and body. Supports status, header, text-body, and JSON-body assertions.
Customer impact it catches: A public page, portal, or API endpoint that is down, returning errors, redirecting incorrectly, timing out, or serving the wrong content.
Lifecycle: Live.

TCP

What is checked: Opens a TCP connection to a host:port to confirm the port accepts connections within the timeout.
Customer impact it catches: A customer-facing service behind a port — SMTP, a control panel, an API gateway, or a custom application daemon — that is no longer accepting connections.
Lifecycle: Live.

DNS

What is checked: Resolves a hostname and validates the returned DNS records (A, AAAA, CNAME, MX, TXT, NS) with record-level assertions.
Customer impact it catches: Unexpected DNS drift, a missing or wrong public record, or a mail/record change that breaks reachability — confirmed from outside your own network.
Lifecycle: Live.

Operator-assisted checks

The data is real and stored, but a Faciotech operator runs these on request while the native, self-serve monitor is being completed. Ask support to enable them for your services.

SSL / TLS certificate

What is checked: Inspects a host's TLS certificate chain, hostname match, days-to-expiry, issuer/subject, and subject-alternative names.
Customer impact it catches: A certificate about to expire, a hostname mismatch, or a broken trust chain — before browsers start warning your customers.
Lifecycle: Operator-assisted. (A first-class automated SSL monitor is planned.)

Heartbeat (dead-man's-switch)

What is checked: A scheduled job checks in on an expected interval; the monitor is flagged missed when a check-in is overdue past its grace window.
Customer impact it catches: A backup, sync job, import, or scheduled report that silently stopped running.
Lifecycle: Operator-assisted. (First-class missed-run incidents are planned.)

Website-change watch

What is checked: Compares a page's current content hash against a baseline and reports changed on drift.
Customer impact it catches: An unexpected content change, a defaced or broken page, or incorrect maintenance copy going live.
Lifecycle: Operator-assisted.

Planned monitor types

Present in the product model but not yet a fully wired probe. Do not rely on these today.

ICMP (Ping) — host reachability via ICMP echo. Planned.
UDP — probing a UDP service with a bounded request/response. Planned.

How subscribers follow a status page

Once a service is monitored and attached to a public status-page component, the customer-facing flow is:

A check fails on the automated checker (or an operator records a finding).
Confirmation rules apply — retries and, where configured, multi-location evidence — so a single noisy result does not become a public outage.
A status report or incident is published, mapping the failure to the affected public component with a plain-language update. Internal detail (hosts, providers, probe routing) stays private.
Subscribers are notified through the channels enabled for the workspace (see the matrix below).
Updates and resolution are appended to the same incident timeline, and a maintenance window can suppress alerts for planned work on the affected scope.

Subscribers can follow a page by email, and machine consumers can poll the public RSS, Atom, and JSON feeds for the same incident and maintenance updates.

Notification channels support matrix

What a workspace can actually send depends on what is configured for that deployment. Treat email as the default; everything else requires setup and a verified test send before you rely on it.

Channel	Default availability	Notes
Email	Available by default	The baseline channel for subscribers and alert recipients.
Webhook	Where configured	Custom HTTP POST endpoint; verify with a test send before relying on it.
Slack	Where configured	Incoming-webhook based; enable per workspace.
Microsoft Teams	Where configured	Enable only after a successful test notification.
SMS	Where configured by plan	Delivery varies by country/route; confirm with support.
RSS / Atom / JSON	Available on public pages	Read-only feeds of incident and maintenance updates.

Other channels referenced in the upstream notification reference (Discord, Telegram, PagerDuty/Opsgenie, and similar) should be considered planned or deployment-specific for FTStatus: do not advertise them publicly until the credentials, test send, and failure behavior are verified for your workspace.

Understanding uptime monitoring — the "why" behind these checks.
Probes, locations, and regions — how and where checks run.
Status reports and incidents — turning a failed check into a customer update.
Notification channels reference — the full per-channel configuration detail.