Docs · LLMs and developers
Version3.12.1Remember operational signals from alerting and telemetry systems.
Observability
Observability sources let an organization remember important alerts, logs, and metrics from operational systems.
Create and manage observability sources from the organization dashboard under Integrations > Observability.
When to use an observability source
Use an observability source when incidents, alerts, logs, or metrics should become part of shared organizational memory.
Observability sources are best for operational events that explain what happened, when it happened, which service was affected, and what the team did next.
Create a source
Select New observability source, then provide:
- Source name: a human-readable name for the source.
- Provider: Sentry, Datadog, or PagerDuty.
- Signal type: Alert, Log, or Metric.
- Memory event type: the event label assigned to incoming signals.
Supported direct providers today are Sentry, Datadog, and PagerDuty. Use Connectors, Webhooks, or API Sources for other operational systems.
Operations
Observability sources can be paused, resumed, or archived from the Observability tab.
- Active sources are available for ingestion.
- Paused sources remain configured but do not ingest new signals.
- Archived sources are retired and should not be used for new ingestion.
Troubleshooting
If operational signals are not appearing in memory:
- Confirm the source is active.
- Confirm the provider and signal type match the sending system.
- Confirm the upstream alerting or telemetry system is configured to send events.
- Check whether the same system is better represented as a Connector, Webhook, or API Source.
Related pages
- Connectors — authorize popular apps and tools.
- Webhooks — receive signed events from external systems.
- API sources — read records from APIs that are not available as connectors.
- MCP — snapshot resources from connected MCP servers.
- Organization — manage organization settings and access.