Monitors

Monitors answer the question your telemetry cannot: is the service actually reachable from the outside? Traces and logs only exist while requests arrive. A monitor keeps probing on a schedule, so you find out your site is down before a user tells you.

They live under Monitors in the sidebar, with tabs for the monitors themselves, Status Pages, and Post-Mortems. The badge counts the monitors currently down on the current project. Every monitor across all of the organization's projects, with uptime, latency, and incident history, is on the Organization Overview.

Check types

• HTTP probes a URL like Postman would: method, headers, auth (basic, bearer, or a custom header), request body, and a set of expected results. You can assert on status codes, response body content (substring or regex), a maximum response time, and a minimum number of days before the TLS certificate expires. With no status assertion, anything below 400 counts as up.
• TCP connects to a host and port, optionally over TLS, optionally sending a payload and asserting on the response. Useful for databases, SMTP, or anything that is not HTTP.
• Browser — not available yet. See Browser checks below.

Every check has an interval (30 seconds to 24 hours), a timeout, and a failure threshold. The threshold is flap damping: a check only transitions to down after that many consecutive failures, so one flaky probe does not page anyone at 3am.

All monitors probe from TracePath's own infrastructure, so the target has to be reachable from the public internet. A check that resolves to a private or LAN address is refused. There is no single-region guarantee and no choice of probe location today; if either matters to you, say so at [email protected].

How runs work

A scheduler enqueues each due check into a durable run queue in the main database, and executors claim runs from it. Results land in the telemetry store, so uptime and latency charts use the same retention and aggregation machinery as everything else.

Two properties matter operationally:

• A probe never runs late. A queued run that outlives its window (the check's interval, capped at five minutes) is recorded as missed, not executed. A stale "is it up" answer would corrupt the uptime timeline.
• Downtime of TracePath itself shows as a gap, not as uptime. If the backend was off, no runs existed, and the charts show unknown rather than a fabricated 100%.

Alerting

Add a notification rule of type Monitor Down on the Alerts page. It fires when any monitor in the project crosses its failure threshold, and sends a recovery notice when the check comes back. Pointing the rule at an escalation channel opens an on-call page instead; the page deduplicates per check, and recovery resolves it automatically, so a blip at night that recovers by itself never needs a human.

Status pages

A status page publishes the uptime of selected monitors at /status/<slug>: a branded light page with 90 days of per-day uptime bars (green operational, amber partial outage, red major outage, gray no data), incident history, and no login required. Create one under the Status Pages tab on the Monitors page (organization admins only), pick the monitors, choose a slug, and toggle it public. Branding: a title, an optional description, and an uploaded PNG/JPEG logo. Latency numbers stay internal; the public payload only carries availability.

Custom domains

Each status page can carry a custom domain (for example status.acme.com):

1. Set the domain on the status page.
2. Create a DNS CNAME from that hostname to app.tracepath.dev.
3. Mail [email protected] with the hostname so a TLS certificate is issued for it. Until that is done the CNAME resolves but the browser rejects the certificate.

Once the certificate is in place, anonymous visitors reaching that hostname land on the status page automatically. Custom domains are one hostname per status page and must be unique across all of TracePath.

Incidents and post-mortems

Monitors feed a full incident-management workflow, covered in depth in Incidents & Post-Mortems:

• Incidents open and resolve themselves from monitor state transitions, with an automatic Investigating and Resolved timeline. Outages your monitors missed can be recorded by hand on a status page, backdated if needed; manual incidents never change uptime numbers.
• The public story is yours to tell. Give incidents public titles and post statuspage-style timeline updates (Investigating, Identified, Monitoring, Update, Resolved). The last 90 days appear in the Past Incidents section of the public page; probe error messages stay internal.
• Post-mortems are internal write-ups in the Post-Mortems tab, owned by the project like the monitors themselves: a WYSIWYG markdown editor with a raw-markdown toggle, tags, an optional link to the incident (one per incident), a full edit activity log, and search across titles, content, and tags. They never appear on public status pages.

Browser checks

The design is a real @playwright/test (opens in a new tab) spec written in a code editor on the check itself, so a login flow or a checkout journey becomes the uptime probe, with a screenshot and the Playwright output stored on every failure. What is missing is the execution fleet: a browser check runs arbitrary customer-authored JavaScript, which needs isolated workers rather than the API hosts, and that fleet is not running yet.

HTTP and TCP checks are unaffected and fully supported.

Limits

The number of monitors an organization can run is set by its plan — 10 on Free, and higher on the paid plans. See Billing for the exact figures. Creating a monitor past the limit is refused with 422 and a message naming the limit; pause or delete one, or upgrade.

Individual check settings are bounded too, and each answers 422 when exceeded:

Run history and the uptime and latency charts are kept for 90 days.