# Modules

> Checkend is one product with four modules. Analytics is available now; errors, logs and uptime are plans.

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. |

> **Note**
> Only analytics is available in this version. Errors, logs and uptime are not started. The sections about them below are plans, not features. The plans can change.

## 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.

## What the modules share

| 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](/docs/start/quickstart.md).

## Errors (coming)

> **Note**
> Coming. This module is a plan. Nothing in this section is built.

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)

> **Note**
> Coming. The SDK is a plan. Nothing in this section is built. Today, only the analytics script tag exists.

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)

> **Note**
> Coming. This module is a plan. Nothing in this section is built.

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)

> **Note**
> Coming. This module is a plan. Nothing in this section is built.

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.