Docs
Get started with Foam
Foam monitors your production services and investigates incidents autonomously. It ingests traces, logs, and metrics over standard OTLP and connects to your codebase for root-cause analysis. The agent surfaces incidents worth your attention, pings the right engineers in Slack with the analysis, and proposes fixes as pull requests.
What Foam collects and why
To find the root cause of an incident, Foam needs three types of data from your services.
- Traces
- The path a request takes through your system, service by service. When checkout fails because a downstream config change flooded a connection pool three services away, traces are how Foam follows that chain. Without traces, you'd only see the symptom, not the cause.
- Logs
- What your code is actually saying at runtime. Error messages, warnings, state changes. Foam uses logs to understand what happened inside a service at the moment something went wrong. Your existing
console.logandconsole.errorcalls get captured automatically. No need to replace them. - Metrics
- Numbers over time: request rates, error rates, latency, memory usage. Foam uses metrics to spot when something deviates from normal. A sudden spike in database writes or a 3x increase in latency is often the first signal that something is off, even before errors start appearing.
OpenTelemetry native
Foam ingests OpenTelemetry over OTLP. No proprietary agent, no custom protocol.
If you're already OTel-instrumented, add Foam as a second exporter pointing at otel.api.foam.ai. Any OpenTelemetry SDK or the OpenTelemetry Collector can target it directly. If you're not, the Foam SDKs (thin wrappers around the upstream open-telemetry libraries) can get you there.
Foam has been built to be a parallel destination. OTLP supports multiple exporters per pipeline, so whatever else is already shipping telemetry from your services (Datadog, Sentry, runtime logs) keeps working unchanged with Foam running alongside.