Monitoring endpoints

An endpoint is anything you want Canary9 to watch: a website, an API, a database port, or a DNS record. This guide walks through creating one and choosing the right check type.

Create an endpoint

From the dashboard, open Endpoints in the sidebar and select + Add endpoint. You'll see the new-endpoint form:

Fill in the fields:

• Name: a label you'll recognise in the dashboard and alerts (e.g. "Marketing site" or "Checkout API").
• URL / host: what to check. For web checks, the full URL (https://api.example.com); for TCP, the host (a port field appears); for ping and DNS, the hostname.
• Check type: how Canary9 probes the target. See check types below.
• Interval: how often the check runs. Each plan sets its own fastest interval (every 5 minutes on Free, every 1 minute on Startup and Pro, every 30 seconds on Enterprise), and you can always choose a slower one. The form opens on the fastest interval your plan includes; anything faster is listed but not selectable, with a link to upgrade. See Plans & billing.

Select Save and the endpoint begins reporting on its next interval. Within a few minutes you'll have uptime history and a response-time graph.

Monitoring locations

Canary9 runs its checks from probe nodes in multiple AWS regions, so you can watch your service from where your users actually are, and catch regional problems a single vantage point would miss. The Check from field on the create and edit forms lets you choose the location(s) each check runs from.

• Pick up to two locations per endpoint. The picker is searchable: start typing to filter the list.
• Sensible default: if you don't pick one, Canary9 assigns a location automatically, so every endpoint is covered from the moment you save it.
• Check from more than one place: select two and Canary9 runs the check from each, giving you a second opinion before you trust a single region's view.
• Change it anytime from the edit form. Your history is preserved.

Each endpoint shows its locations as a badge in the list, so you can always see where a check runs from at a glance:

Comparing locations on the chart

When an endpoint checks from more than one location, its response-time chart overlays one line per location on a shared time axis and scale, so a real difference between regions reads as real separation on the chart, not an artifact of two separate y-axes.

• A small legend below the chart names each location (in color) and shows its own average latency, p95 latency, and uptime, so you can tell at a glance which location is slower or less reliable.
• Uptime, downtime gaps, and pause markers stay whole-endpoint. They describe the endpoint as a whole (a gap means no location reported), so they're shown once, not duplicated per location.
• Single-location endpoints are unaffected: the chart renders exactly as a single line, with no legend, until you add a second location.

Track status at a glance

The Endpoints page lists everything you monitor with its current state, latest response time, and uptime. Select any row to open its detail view with response-time graphs and recent check history.

Check types

Canary9 supports five check types. Pick the one that matches what you need to verify:

HTTP vs. browser checks

An HTTP check is fast and lightweight: it confirms your server answered. A browser check actually renders the page in Chromium, so it catches broken JavaScript, failed asset loads, and visual regressions, and stores a screenshot you can review from the endpoint's detail view.

Verify response content (HTTP checks)

A status code alone doesn't always tell the whole story: a page can return 200 OK while showing an error page, a maintenance banner, or a stale cached response. HTTP checks can optionally assert on the response body as well as the status code, from the create or edit form's Content check field:

• Keyword: the response body must contain (or must not contain) an exact piece of text, e.g. "status: ok".
• Regex: match a PCRE-style regular expression instead of literal text, e.g. version:\s*\d+. Patterns are evaluated with Python's re engine, which supports the familiar PCRE syntax (character classes, groups, alternation, anchors, lookarounds).
• Invert the match: tick "Fail if body matches" to flip the rule around, so the check fails when the pattern is found. Handy for catching a maintenance-mode banner or an error string that should never appear.

When a content check fails, whether from the wrong status code or a content mismatch, Canary9 captures a short excerpt of the response body and shows it alongside the error in the endpoint's detail view, so you can see exactly what came back without needing to reproduce the failure yourself.

The Overview dashboard

Overview is your at-a-glance home: every endpoint with its current health, target, check type, and interval. Select any monitor to jump straight to its detail view on the Endpoints page.

The health indicator reflects the most recent check, using the same colours as the status bars on the Endpoints page:

• Up (green): the last check passed.
• Degraded (amber): the last check passed but returned a 4xx status or was slow.
• Down (red): the last check failed.
• Blocked (violet): a CDN's bot management refused the probe. This is not treated as an outage.
• No data (grey): the endpoint is active but no result has arrived within its missing-data window (three check intervals, at least five minutes).
• Pending: a newly created endpoint waiting for its first check.
• Paused: monitoring is switched off for this endpoint.

The footer summarises how many endpoints are in each state, and the page refreshes on its own every 30 seconds.

Find & organize endpoints

As you add more endpoints, a few tools keep the list manageable:

• Filter: the search box matches names and targets, and supports filters: type:http, label:prod, and enabled:true / enabled:false. Combine them, e.g. type:http label:prod.
• Labels: tag endpoints (with a colour) from the edit form to group them by team, environment, or service, then filter by label.
• Time range: switch the whole list between 1h, 3h, 6h, 12h, 24h, and 7d to widen or narrow the history shown.
• Pause / resume: the toggle on each row stops or restarts checks without deleting the endpoint.
• Edit / delete: the ⋯ menu opens an inline editor (name, target, type, interval, labels) or deletes the endpoint after a confirmation.

Reading the data

Each row shows a status history strip: one bar per time bucket, green for healthy, amber for slow or 4xx, red for errors, grey for no data. Expand a row for the full detail view:

• Response-time chart: latency over the selected window, with uptime %, average, and p95 headline stats. Downtime gaps are shaded so you can see exactly when things broke. Endpoints checked from more than one location show one overlaid line per location with a legend; see Comparing locations on the chart.
• HTTP checks show a request breakdown for DNS, connect, TLS, and time to first byte (TTFB). When a check fails, Canary9 highlights the phase that failed and shows the underlying error, plus a captured response excerpt when one is available. If a pooled connection was reused, connect and TLS correctly appear as not applicable for that request.
• Phase timing chart (HTTP checks): the request phases as a stacked chart over time directly under the latency chart, with bands for DNS, connect, TLS, and TTFB, so you can see why a check was slow, not just that it was (e.g. a latency spike that is all TLS handshake). Hover any point for that specific check's phase-by-phase waterfall, including the transfer remainder so the numbers always add up to the total; failed checks are marked and their failing phase highlighted. Monitoring gaps are shaded on the same timeline as the latency chart. When an endpoint checks from more than one location, region tabs above the chart let you view one location at a time, so each region's phases render on their own scale.
• Statistics: a compact section (open it from the panel footer) with a p50 / p95 / p99 latency strip, the status-code distribution for the window (2xx/3xx/4xx/5xx with counts and shares), and a failure-by-phase breakdown showing which request phase your failures happen in. Long windows are summarized server-side, so a 7-day view stays fast.
• Network diagnostics: the Diagnostics button at the bottom of the panel runs a full on-demand diagnostic chain from the probe's location: DNS resolution, hop-by-hop network path, port status, TLS handshake, and the response. See Diagnostic chains for how to run one and read the results.
• HTTPS checks show the peer certificate's expiry date and a live days-remaining countdown. The last known expiry stays visible during a later network outage, when a new certificate cannot be observed.
• Uptime stat: the time-weighted share of the selected window your endpoint was verifiably up. See Uptime % and SLA reporting below.
• DNS checks show what the name currently resolves to plus a short history of record changes.
• Browser checks show a screenshot of the rendered page alongside the load-time chart. It opens on the latest screenshot; click any highlighted point on the chart to view the screenshot captured at that moment, then jump back to the latest with one click.

Uptime % and SLA reporting

Every endpoint detail view has an Uptime stat that follows the page's time-range selector, so the percentage always describes the same window as the charts and status bars around it. It is time-weighted: the number describes how much of the window your endpoint was verifiably up, not just the share of recorded checks that passed.

• Missing data counts as downtime. If checks should have run but nothing was recorded (a monitoring gap), that time counts against uptime rather than being quietly skipped. A window with a visible hole in the chart can't report 99.9%; the headline stat, the chart summary, and the API all agree on the same figure. The check counts (e.g. "9,440 / 9,447 checks succeeded") stay visible as supporting detail.
• A brand-new endpoint never shows an alarming number. Right after you create an endpoint there's no data yet, so Canary9 shows "Collecting data…" until at least one full check interval has passed, rather than a misleading 0% or 100% from a single sample. Time before the endpoint existed is never counted against it, even on a wide window like 7d. The status bars and chart make the same distinction: time from before the endpoint existed is grey, a gap where checks should have run but nothing was recorded is highlighted in red, and time the monitor was deliberately paused shows in amber. The chart also draws vertical marker lines at the moment an endpoint was created, paused, or resumed, so you can line events up with the latency data around them.
• Paused time is neutral. Time you deliberately paused the monitor is excluded from the calculation entirely; it neither inflates nor hurts the percentage. A window that was paused throughout reads "No data" instead of guessing at a number.

For customers who need to report against a contractual SLA target (e.g. 99.9%), the API also exposes a monthly uptime-vs-target report per endpoint, with a CSV export for sharing with stakeholders. Reach out at sales@canary9.com if you'd like this surfaced in the dashboard for your plan.

These reports measure your endpoints. For what Canary9 commits to for its own platform, including the five-nines target, outage definitions, and reimbursement, see Service commitments.