Modules

View as Markdown

Checkend is one product with four modules. All modules run in one binary on one server. They share one timeline, one query core, one MCP server and one CLI.

Module	Status	What it does
Analytics	Available	Private web analytics, joined with Google Search Console and Bing Webmaster Tools data.
Errors	Coming	Error tracking through the Checkend SDK.
Logs	Coming	Log ingest, archive and search.
Uptime	Coming	Endpoint checks from many regions.

Why one product

One story. “What broke, why, and did the fix work” needs one timeline.
One agent connection. One MCP server with one set of concepts gives better agent results than four.
One operation. One install, one backup, one sign-in, one upgrade.

Shared part	What it does
Projects	A project holds sites. Later modules add services and endpoints to the same project.
Timeline	Releases and annotations show in one place.
Query core	The web UI, the REST API, MCP and the CLI read through one query layer. They give the same numbers.
Findings	Rules make findings with evidence.
Outcomes	An agent makes a change. Checkend measures if it worked.
No AI inside	Checkend calculates facts. Your agent does the thinking.

Analytics

Analytics is available now. It has:

a tracking script under 2 KB gzip, with page views, custom events, outbound links, file downloads, 404 pages and web vitals,
three privacy modes, without cookies,
channels, goals, conversions and revenue for each currency,
Search Console and Bing data, a page crawler, URL inspections and IndexNow,
AI crawler hits from your access logs,
findings, annotations, measured outcomes and the brief,
scheduled reports and signed webhooks.

Start with the Quickstart.

Errors (coming)

The plan: error tracking through the Checkend SDK (see below). The plan includes issue grouping, secret scrubbing before storage, source maps, and an issue brief for a coding agent. It also includes a fix loop: an agent links a fix, CI reports the deploy, and Checkend checks that the error does not come back.

The Checkend SDK (coming)

The plan: one Checkend SDK for each language. One setup and one Checkend key send analytics, errors, app logs and job check-ins. A plain HTML site uses the same SDK as one script tag. For a script tag, the Checkend settings select the parts, and the HTML does not change.

The SDK comes with the errors module. The first SDK is for JavaScript, in the browser and in Node.js. Python, Ruby, Go and PHP come next.
The current analytics script becomes the analytics part of the JavaScript SDK. Its tag keeps working, and it stays under 2 KB gzip.
The Checkend key holds the server address and a public key. The key can only send data to one project. It cannot read data, so it is safe in a browser.
To move an app from another tool, you make one change, for example one line in package.json. The SDK recognizes the old calls, for example the calls of the Sentry SDK. It sends their data to Checkend and shows the Checkend call to use instead. The server keeps the Sentry and OpenTelemetry endpoints during a migration.

Outside uptime checks, server logs and source maps do not use the SDK.

Logs (coming)

The plan: log ingest with OpenTelemetry (OTLP) over HTTP, syslog and journald directly, and JSON lines over HTTP. It includes a live tail, search by time, service, severity, fields and text, and a link from logs to errors by trace ID. Logs is planned as the last module.

Uptime (coming)

The plan: HTTP and TCP checks from many regions, with the checks on Cloudflare Workers in your own Cloudflare account. The main server keeps the configuration, the results and the reports. The plan includes an alert from the Worker when the main server does not answer.

Each module alone

The plan is that each module also works alone, with its own docs and its own install. Each module gets its own disk budget, so that one module cannot fill the disk for another.