Skip to main content
Telemetry is in early access. To turn it on for your workspace, book a call or ask in Discord.
Your apps send logs, traces, and metrics to Superlog. Superlog stores them, groups exceptions into error issues, checks alerts and synthetic checks on a schedule, and posts to Slack when something is wrong. Agents read the same data through the MCP server and automations. Here is how a typical project uses Superlog to stay reliable: Telemetry flows from web apps, backend services, and cloud integrations into Superlog logs, traces, and metrics. Dashboards show the state of your system, alerts notify you when things break, and error fingerprinting helps discover new failure modes. Agents read the same telemetry. Synthetic checks monitor endpoint availability. Telemetry flows from web apps, backend services, and cloud integrations into Superlog logs, traces, and metrics. Dashboards show the state of your system, alerts notify you when things break, and error fingerprinting helps discover new failure modes. Agents read the same telemetry. Synthetic checks monitor endpoint availability. Alerts, error notifications, and failing synthetic checks post to Slack. Agents read the same data through the MCP server and automations.

1. Your apps send telemetry

Backend services send OpenTelemetry over OTLP/HTTP to your region’s ingest endpoint with an ingest key. Browser apps send with the Superlog browser SDK. A Collector you already run can forward to the same endpoint. Vercel, AWS CloudWatch, and Google Cloud connect without code changes. The ingest key decides which workspace the data goes to. It can only add data. See Collect telemetry.

2. Superlog stores it by service

Every record keeps its resource attributes. service.name and deployment.environment.name are the ones Superlog groups and filters by. Each log record can carry the trace and span IDs of the request that wrote it, so you can go from a log line to its trace. When each service passes W3C trace context to the next, one user action becomes one trace, from the browser to every backend service and queue it reaches.

3. You explore it

  • Logs: search and filter log records.
  • Traces: find slow or failing requests and open a trace to see every span.
  • Metrics: chart any metric your services send.
  • Dashboards: put the charts your team watches on one shared page.

4. Superlog detects problems

Errors work without setup: exceptions are grouped into issues as they arrive. Alerts and synthetic checks are rules you create.

5. Your team hears about it in Slack

Error notifications, alerts, and synthetic checks post to the Slack channels you choose. Recoveries reply in the same thread. You can resolve or silence an error from its Slack message.

6. Agents investigate

  • MCP server. Claude Code, Cursor, Codex, and other agents query your logs, traces, and metrics, read error issues, and create dashboards, alerts, and checks. See Install Superlog MCP.
  • Automations. An automation can start on a new or regressed error, or on an alert or check message in a Slack channel it watches. It runs a coding agent with your repositories, finds the cause, and can open a pull request. See Automations.

Where to start

Instrument your app

Create an ingest key and send your first data.

Make your application reliable

Set up dashboards, alerts, and notifications with one prompt.