Skip to main content

​
Testing Workflow

Use local testing to confirm Beacon is installed, writing endpoint events, and readable through local review tools before you move into managed deployment or log forwarding. Beacon runs locally by default. These checks use the endpoint runtime JSONL log and local-only commands, so you can validate collection without a Beacon-hosted account or external network dependency.

​
Validation workflow

1

Check endpoint health

Run beacon endpoint status and beacon endpoint doctor to confirm the endpoint configuration, collector, runtime log, and local service state.
2

Write a validation event

Use beacon endpoint test-event to append a known-good synthetic event to the runtime JSONL log.
3

Review the dashboard

Start beacon endpoint dashboard --open and confirm the validation event appears in Log Search and summary views.
4

Validate MCP access

Run beacon mcp doctor, then test an MCP query path against the same runtime log to confirm local assistants only receive the intended compact activity summaries.
5

Inspect local logs

Confirm the runtime JSONL path, last-event freshness, and user or system mode paths match your test scope.

​
Guides

Endpoint validation

Confirm endpoint health, write validation events, and inspect the runtime JSONL log.

Dashboard testing

Review Log Search, Security Overview, and runtime inventory from the local dashboard.

Model Context Protocol (MCP)

Test local MCP tools and connect Cursor or Claude Code to Beacon activity.
For ephemeral Claude Code telemetry in CI jobs, see CI Telemetry.

​
When to use local testing

Local testing is useful for developer evaluation, support triage, security review demos, and pilot preparation. For managed rollout guidance, see For Security & IT Teams, MDM Deployment, and Log Forwarding.