Docs

Getting started

1. Create an organization. The organization stores monitors, recipients, reliability settings, and team access. Its owner is automatically added as an enabled alert recipient using the account email.
2. Create monitoring coverage. Open Monitors and choose New monitor. Guided website setup creates recommended HTTP, DNS, TLS, and browser coverage from one URL; individual monitor types remain available for targeted configuration.
3. Select recipients. Attach one or more recipients to each monitor so unhealthy transitions reach the right people.
4. Review collected results. Monitor details show recent executions, while Overview and Reliability turn ringstore history into trends, budgets, and operational context.

Overview dashboard

Overview organizes monitoring data into tabs by monitor type.

• Uptime and duration summarize recent success rates and average execution time with monitor-level tables and trends.
• Health heatmaps distinguish healthy, unhealthy, and empty time buckets. Empty buckets mean no scheduled result was recorded; they are not treated as failures.
• Reliability calendars and tail latency show longer-term daily health and p50/p95/p99 behavior when enough history exists.
• Fingerprints, similarities, and regressions highlight changes in performance shape and monitors whose behavior moves together.

Monitor management

The Monitors inventory is the central place to search, filter, create, inspect, edit, and delete monitors.

• Every enabled monitor runs on its configured schedule. Initial jitter spreads load; later runs stay on fixed deadlines, and slow executions may overlap.
• Monitor detail pages show configuration and recent run history. Browser performance monitors can also expose the latest captured screenshot.
• Run timestamps represent actual execution start time. Displayed duration remains the measured execution length.
• Retention limits bound recent Postgres run history. Long-term aggregated trends remain available through ringstore according to its configured rings.

Monitor types

• HTTP validates availability, status, latency, response content, headers, redirects, and request configuration.
• HTML Performance loads a page in Chrome and records browser timings, web vitals, and screenshots.
• HTML Accessibility runs axe-core rules and evaluates violation-count thresholds by severity.
• JavaScript Errors observes browser console errors and log volume.
• DNS checks resolution, expected answers, name servers, and domain metadata.
• TCP checks whether a host and port accept a connection.
• TLS checks certificate verification, hostname, protocol, and expiry.
• SSH observes host keys, banners, and negotiated algorithms for availability and drift.

Alerts and recipients

Recipients are organization-scoped email destinations that can be attached to multiple monitors.

• SiteCanary notifies selected recipients when a monitor transitions from healthy to unhealthy. Repeated unhealthy results do not send duplicate transition notifications.
• The Alerts view records alert history with the monitor, target, status, and failure context.
• Manage recipient names, addresses, and enabled state under Settings → Recipients.

Incident workflow

Incidents collect reliability events and the monitors affected by them.

• Open an incident to review affected monitors, its timeline, and an automatic summary when one is available.
• Add timeline notes or move the incident through acknowledged, resolved, and reopened states.
• Incident summaries compare reliability before, during, and after the event and may identify the likely failing layer.

Reliability tools

Open Reliability to choose between objective and capacity tools or reporting and communication tools.

• SLOs track rolling availability objectives, error-budget remaining, data coverage, and forecasts over 7-, 28-, or 30-day windows.
• Guardrails compare p95 latency or response size with a configured limit over a rolling window.
• Reports archive weekly and monthly summaries generated by canaryd, including SLO compliance and incident counts.
• Public status publishes selected monitors under safe display names for customers.
• Reliability insights and recommendations surface prioritized incidents, SLO burns, changes, and deterministic suggestions. Recommendations change configuration only after explicit acceptance.

Annotations and integrations

Annotations record deployments and operational changes so they can be compared with monitoring history.

• Add an annotation in the UI with its occurrence time, environment, service, version, URL, and note.
• Create an ingestion token for CI or deployment automation. The plain token is shown only once; copy it before leaving the response.
• Send token-authenticated annotations to POST /api/v1/annotations and revoke tokens that should no longer be accepted.

curl -X POST http://localhost:8080/api/v1/annotations \ -H "Authorization: Bearer sc_your_token" \ -H "Content-Type: application/json" \ -d '{"kind":"deployment","service":"api","version":"v1.2.3","occurred_at":"2026-07-12T16:00:00Z"}'

Public status pages

• Create a page privately while selecting monitors and reviewing their safe display names, or select Publish immediately during creation.
• A private page is unavailable at its public URL. Use Publish page when it is ready.
• A published page exposes overall health, per-system status, a 90-day reliability history, recent incidents, and an SVG badge. Unpublishing makes both the page and badge unavailable.
• Only incidents connected to monitors selected for that status page appear publicly. Public incident updates use safe lifecycle labels rather than internal event details.

Organization settings

• Organization profile controls identity, billing email, country, and timezone defaults. The globally unique slug appears in organization URLs.
• Slugs use 3–63 lowercase letters or numbers separated by single hyphens. Changing a slug immediately invalidates links that use its previous value.
• Members controls organization membership and roles.
• Recipients controls alert delivery destinations.
• Authentication defines reusable auth flows that monitors can use before protected requests.
• Scheduling manages adaptive scheduling policies for normal, incident, and stable conditions.
• Integrations provides deployment annotations and API tokens.

History and retention

SiteCanary keeps two complementary forms of history.

• Postgres run rows retain detailed recent executions up to each monitor's configured limit.
• Ringstore keeps bounded aggregate time series for dashboards, comparisons, SLOs, reports, and public reliability history.
• Scheduled deadlines determine ringstore placement. Downtime and skipped deadlines stay empty rather than being backfilled.

Alert transitions

Alerts are sent only when a check transitions from healthy to unhealthy. Recoveries do not trigger notifications.

Auth flow types

Auth flows describe how to obtain credentials before running checks. Select the type that matches how your system authenticates.

• Session cookie login performs a login request and extracts a session cookie for reuse.
• Bearer token captures a token (from JSON or headers) and uses it in an Authorization header.
• API key stores a static key used in headers or query parameters.
• Basic auth stores a username/password pair to send via the Authorization header.
• Custom headers defines fixed headers to attach to requests without additional extraction.

Use Headers JSON and Extractors JSON to define what is sent and what values to capture from responses.

Turnstile sign-in protection

Deployments can optionally require Cloudflare Turnstile on login and signup while leaving authenticated application navigation unchanged.

• Enable it with TURNSTILE_ENABLED=true and configure the site key, secret key, and expected production hostname.
• The browser receives only the public site key. SiteCanary validates each single-use token, hostname, and form action with Cloudflare before checking credentials or creating an account.
• Verification failures fail closed with a retry message. CSRF protection, sessions, and normal authentication checks still apply.

HTTP redirects

Follow redirects controls whether the HTTP client follows 3xx responses. Fail on redirects marks the check unhealthy if any redirect response is observed, even when redirects are not followed.

HTTP status codes

When a specific status code is selected, the response status must match exactly. Leaving the field empty allows any status code.

HTTP Content-Type matching

Content-Type matching compares the response header value before the first semicolon (e.g., text/html from text/html; charset=utf-8), case-insensitive.

HTTP required response headers

Each selected response header must be present and non-empty in the response.

HTTP body contains

Comma-separated values are compared as lowercased substrings against the response body. Every entry must be present.

HTTP body not contains

Comma-separated values are compared as lowercased substrings against the response body. Any match causes an alert.

HTTP response time threshold

Response time is measured as the total check duration, including DNS, connection, TLS, and HTTP processing.

HTTP security headers

SiteCanary's deployed web application emits CSP and HSTS on HTTPS responses, along with clickjacking, MIME-sniffing, referrer, and browser permissions protections.

When "Check security headers" is enabled for HTTP checks, SiteCanary validates the following headers on HTTPS responses:

• Strict-Transport-Security (HSTS) must be present and non-empty.
• Content-Security-Policy (CSP) must be present and non-empty.

Checks are skipped for non-HTTPS URLs.

HTML Performance TTFB

Time to First Byte is measured from navigation request start to response start, in milliseconds.

HTML Performance DOMContentLoaded

DOMContentLoaded is measured from navigation start to the DOMContentLoaded event end, in milliseconds.

HTML Performance Largest Contentful Paint

Largest Contentful Paint is captured from browser performance entries and reported in milliseconds.

HTML Performance Cumulative Layout Shift

CLS is the sum of layout shift scores that did not follow user input. Lower is better.

HTML Accessibility (axe-core)

HTML Accessibility checks run an axe-core scan in headless Chrome and count violations by impact (critical, serious, moderate, minor).

Thresholds are counts. If any enabled threshold is exceeded, the check is marked unhealthy.

DNS expected answers

Expected answers are compared against resolved A/AAAA results for the hostname. If any expected answer is missing, the check is marked unhealthy.

TLS expiry threshold

TLS checks alert when the earliest certificate expiry in the chain is within the configured number of days.

TCP connectivity

TCP checks alert when a TCP connection cannot be established to the configured host and port.

SSH host key alerts

SSH checks capture the server host key fingerprint (SHA256), banner, KEX algorithm, cipher, and MAC from the negotiated handshake.

When "Trust on first use" is enabled, the first successful check saves the host key fingerprint and algorithm for future comparisons.

Alerts fire when any enabled comparison changes (host key, banner, KEX, cipher, or MAC) or the host key does not match the configured fingerprint.