Overview
What PulseTrace is, how a monitor becomes an incident, and where each part of the product lives.
PulseTrace is a monitoring platform for the things that quietly break your users: endpoints, certificates, DNS and domains, and whole API workflows. You add a monitor, it is probed on the interval you choose, and every result lands on one timeline.
That timeline does the work: it opens and resolves incidents, learns each signal's normal to flag anomalies, grades your TLS security posture, records what changed outside your code, and turns it all into reports, a public status page and alerts in the tools you already use — and, because it speaks MCP, into your AI clients too.
The objects you will meet
| Object | What it is | Where |
|---|---|---|
| Monitor | One thing being checked: a URL, host, port, name, certificate or multi-step journey. Has a type, a target, an interval, regions, tags and a type-specific config. | Monitors |
| Execution / result | One run of a monitor: status, timing, the assertions evaluated and, for HTTP, the response excerpt. | Alerting |
| Incident | Opened when a monitor trips its failure threshold; resolved on recovery; acknowledge and assign in between. | Incidents |
| Notification destination | An organization-level place alerts go: Slack, Teams, Discord, Telegram, PagerDuty, Opsgenie, incident.io, Rootly, email, a signed webhook. | Destinations |
| Anomaly / change event | Intelligence output: a latency episode outside the learned baseline, or a diff in DNS, TLS, headers, redirects or content. | Intelligence |
| Status page / trust page | Public pages fed by the same monitors — uptime history, and optionally security grades. | Status pages |
| Report | Availability, performance, SLA, incidents, intelligence and monitor-health — on demand, exported, or scheduled to a destination. | Reporting |
| API key / service account | How automation authenticates: scoped keys, optionally owned by a non-human service account. | API keys |
How a check becomes a page
- The scheduler enqueues each monitor on its interval; a monitor-worker executes it and writes the result.
- The worker keeps a status per monitor. After
failure_thresholdconsecutive failures it flips to down; aftersuccess_thresholdconsecutive successes it flips back to up. Only a flip notifies — a monitor that fails once and recovers is not an alert unless the threshold is 1. - A flip to down opens an incident and sends the
downevent to the monitor's destinations. Recovery sendsrecoveredand resolves it. While it stays down, reminders go out at 4 h, 8 h and then every 24 h. - Maintenance windows and dependencies suppress what you have told PulseTrace to expect.
These docs describe the current build. Where a capability is still in progress — multi-region execution, custom-domain verification for status pages, SSO — the relevant page says so rather than describing what is planned.