@grepr/cli 1.11.5-17c35fd → 1.11.5-1b47e00

package/build/dist/docs-index/6a2c7211-83c4-411e-aa57-7178033cce17.txt

@@ -0,0 +1,171 @@
+Start, follow, and read Grepr AI agent investigations, guide a running one, understand each state, and review the pipeline changes an agent proposes.
+
+# Run and review investigations
+
+An *investigation* is one run of an agent. It holds the signals that triggered it, every turn the agent took, every tool it called, the changes it made outside the sandbox that Grepr recognizes, and the summary it finished with. Investigations are listed on the agent's **Investigations** step.
+
+An investigation is a record, not a conversation. You can interrupt one to add guidance, but most investigations run to completion unattended and you read them afterwards.
+
+## Start an investigation manually \[#start-manual]
+
+Start one manually to try out an agent before subscribing it to anything, or to point an agent at something you already know about.
+
+1. On the agent's page, click **Run investigation**.
+2. Optionally enter **Context**, which is what the agent starts from, such as the service to look at or the symptom you saw.
+3. Click **Start investigation**.
+
+Context is the only instruction an investigation started manually receives beyond the agent's system prompt, so include the service, the time range, and the symptom. An investigation with no context relies entirely on the agent's prompt to decide what to examine.
+
+An investigation you start manually is not subject to the maximum queue wait, but it is subject to the concurrency limit and the token budgets. When a budget is exhausted, a manual investigation is discarded rather than queued, so you find out immediately instead of waiting. See [_](/ai-agents/create-an-agent#limits).
+
+## Investigation states \[#states]
+
+| State | What it means | What you can do |
+| --- | --- | --- |
+| Queued | Accepted and waiting for a free slot on the agent. No sandbox exists yet. | Cancel it. |
+| Running | The agent is working. | Stop it or cancel it. |
+| Stopping | A stop was requested and is being applied. | Cancel it. |
+| Cancelling | A cancel was requested and is being applied. | Wait for it to finish. |
+| Stopped | Either paused and waiting for instruction, or ended after waiting too long. | Resume a paused one, or continue a finished one in a new investigation. |
+| Completed | The agent finished and wrote a summary. | Continue it in a new investigation. |
+| Failed | The investigation ended with an error. | Read the reason, then continue it in a new investigation. |
+| Cancelled | You cancelled it. | Continue it in a new investigation. |
+| Discarded | Recorded but never ran. | Read why, then address the cause. |
+
+Stopped covers two situations, and the status icon tells them apart. A stopped investigation that is still waiting for instruction is paused and can be resumed, carrying on from where it left off while its sandbox is still there. If the sandbox is lost while the investigation is paused, the resumed agent restarts from the triggering signals and whatever you resume it with, so give it what it needs rather than assuming it still remembers. One that waited too long without instruction has ended, and the work it did is readable but no longer resumable. So resume a stopped investigation while you still want its context, rather than leaving it paused indefinitely.
+
+Completed, Failed, Cancelled, Discarded, and a timed-out Stopped are final. Nothing restarts them, though you can start a fresh investigation seeded with what one learned. See [Continue in a new investigation](#continue).
+
+## Read an investigation \[#read]
+
+Open an investigation from the agent's **Investigations** step. It reads top to bottom: what the agent concluded, what set it off, then how it got there.
+
+### The summary \[#summary]
+
+A finished investigation opens with the agent's own account of what it found. An investigation that failed or was discarded carries the reason it ended instead of a conclusion, which is the first thing to read when a run did not work.
+
+The summary is what the agent wrote for you to read, so it is the part to read when you want the conclusion. Read the timeline when you want to check the conclusion.
+
+### The triggering signal \[#trigger]
+
+The triggering signal is the event that started the run. A webhook signal shows the payload the sending system posted. A log pattern signal shows the pattern the reducer detected and a sample log line that matched it. An investigation you started manually shows the context you typed.
+
+Read the signal when a conclusion surprises you. An agent reasoning from a payload whose fields it cannot interpret often produces a plausible but wrong summary, and the fix is usually the integration's schema description rather than the agent's prompt. See [_](/integrations/grepr-agent-webhooks#schema-description).
+
+### The timeline \[#timeline]
+
+The timeline is every step in order: what the agent was told, what it said, each tool it called with the arguments it passed, and what each tool returned. Tool output is collapsed, so you can scan the shape of a run and expand only the calls that matter. Each call reports how long it took.
+
+Read the timeline to answer why an agent concluded what it did. Two patterns are worth recognizing:
+
+* Repeated similar tool calls usually mean the agent is missing a capability or some knowledge, and is working around the gap. Consider enabling a skill that covers the task or using a better model.
+* A run that ends without a conclusion usually means it reached its turn or token limit. The last turn shows where it was.
+
+### Recorded actions \[#actions]
+
+An *action* is a consequential change the agent made outside its own sandbox: a pipeline version it applied, a pipeline change it proposed for review, or a write it made through a connected MCP integration. Reads are not actions, and neither is everything an agent can do from a shell, so treat the count as a record of the changes Grepr recognizes rather than a complete audit. Actions appear beneath the tool call that made them and are counted in the **Actions** column of the list, so you can find the investigations that changed something without reading any transcripts.
+
+Actions record successful changes, not attempts. A tool call that failed appears in the timeline but produces no action.
+
+## Guide a running investigation \[#guide]
+
+### Stop and resume \[#stop-resume]
+
+Stopping ends the agent's session and pauses the investigation. Work already in flight is abandoned rather than finished, so a tool call that was running might not complete. Everything the investigation had recorded up to that point is kept, which is what a resume continues from.
+
+To continue it, click **Resume**. You can add a message to steer it, such as naming the service it should focus on, or resume with no message to let it carry on. Stop and resume when an agent is heading the wrong way but its work so far is worth keeping.
+
+### Cancel \[#end-for-good]
+
+Cancelling ends an investigation for good. Use it when the run is not worth finishing. The transcript remains readable.
+
+To cancel several at once, select them in the list and cancel the selection. This is how you clear a backlog that built up, such as from a misconfigured source. Cancelling is permanent, and an investigation that has already finished is left alone.
+
+### Continue in a new investigation \[#continue]
+
+A finished investigation cannot be resumed, but you can start a new one seeded from it. The new investigation begins with the earlier conversation, and you can add a message to direct it, such as asking it to verify that a change worked.
+
+The seed carries what the agent and you said to each other, not the tool calls it made or the results they returned, and a long conversation is trimmed to its most recent part. Put anything the new investigation must not lose into the message you start it with.
+
+Use this to carry an investigation forward after you have acted on it, rather than starting from nothing and paying for the same discovery twice.
+
+## Find investigations \[#find]
+
+The list holds one row per investigation, with its identifier, what triggered it, its summary, when it was created, how long it ran and how long it waited in the queue, its state, and how many actions it recorded.
+
+Three filters narrow it:
+
+* **Status** limits the list to the states you select.
+* **Actions** separates investigations that recorded a change from those that did not.
+* **Trigger** limits the list to investigations started manually, by a webhook, or by a log pattern.
+
+Filter on recorded actions when you want to review what an agent has changed, and on failed status when you are diagnosing an agent that is not working.
+
+## Why an investigation was discarded \[#discarded]
+
+A discarded investigation was recorded but never ran. There are three reasons, and each has a different fix:
+
+| Reason | What to do |
+| --- | --- |
+| The agent was at its concurrency limit and set to discard extra signals. | Raise the concurrency limit, switch to queueing, or reduce what the source emits. |
+| A queued investigation waited longer than the maximum queue wait. | Raise or remove the maximum queue wait, or raise the concurrency limit so the queue drains faster. |
+| A token budget was exhausted. | Raise the budget that blocked it, or wait for the window to reset. Check which budget it was on the agent's page. |
+
+A rise in discarded investigations usually means a source is emitting more than the agent can handle. Reducing what the source emits keeps the signal you want, whereas raising the limits keeps the volume and increases the cost. See [_](/ai-agents/subscriptions#volume).
+
+## Review the pipeline changes an agent proposes \[#suggestions]
+
+An agent set to require human approval records each pipeline change it proposes as a *suggestion* on that pipeline, and changes nothing until you apply it. Suggestions are on the pipeline's **Suggestions** step, not on the agent, because the decision is about the pipeline.
+
+Each suggestion lists when it was proposed, what it changes, and the investigation that produced it. To decide, review the proposed change as a difference against the pipeline's configuration, and read the investigation that produced it to see the evidence the agent based it on.
+
+Then either apply it or reject it:
+
+* Applying re-verifies the change against the pipeline's configuration as it is now, not as it was when the agent proposed it, and a running pipeline then restarts to pick it up. A suggestion whose assumptions no longer hold is refused rather than applied blindly, and it stays pending, so you can retry it after the pipeline settles.
+* Rejecting leaves the pipeline untouched and closes the suggestion.
+
+Reviewing a suggestion changes nothing on the live pipeline, so read as many as you like before deciding. Suggestions do not expire, but an old one is more likely to be refused on apply, because the pipeline's configuration has likely drifted. Review them while they still match the pipeline.
+
+To let an agent apply its own changes instead, see [_](/ai-agents/capabilities#change-approval).
+
+## Read investigations from the CLI \[#cli]
+
+The Grepr CLI reads investigations, which is useful for auditing many runs at once or feeding them into your own tooling.
+
+```bash
+# List an agent's failed investigations
+grepr investigation:list --agent-id <agent-id> --status FAILED --page-size 10
+
+# Read one investigation's metadata, summary, and recorded actions
+grepr investigation:get <investigation-id>
+
+# Read the turns, including tool calls and their results
+grepr investigation:turns <investigation-id> --page-size 10
+
+# Export a transcript to a file
+grepr investigation:transcript <investigation-id> --all --output investigation.json
+```
+
+To follow a running investigation as it progresses, add `--follow` to `investigation:turns`. To learn more about the CLI, see [_](/cli).
+
+## Frequently Asked Questions
+
+### How do I start a Grepr AI agent investigation manually?
+
+On the agent's page, click Run investigation, optionally enter the context the agent should start from, and click Start investigation. Context is the only instruction beyond the agent's system prompt, so include the service, the time range, and the symptom.
+
+### What does a stopped investigation mean in Grepr?
+
+Stopped covers two situations. An investigation that is still waiting for instruction is paused and can be resumed, carrying on from where it left off while its sandbox is still there. If the sandbox is lost while it is paused, the resumed agent restarts from the triggering signals and the message you resume it with. One that waited too long without instruction has ended, and remains readable but is no longer resumable. The status icon tells the two apart.
+
+### Can I resume a completed Grepr AI agent investigation?
+
+No. Completed, failed, cancelled, discarded, and timed-out stopped investigations are final. You can start a new investigation seeded from the finished one, and add a message to direct it, such as asking it to verify that a change worked.
+
+### Why was my investigation discarded?
+
+There are three reasons: the agent was at its concurrency limit and set to discard extra signals, a queued investigation waited longer than the maximum queue wait, or a token budget was exhausted. The agent's page reports which token budget blocked it and when the window resets.
+
+### How do I review a pipeline change proposed by a Grepr AI agent?
+
+Suggestions appear on the pipeline's Suggestions step. Review the proposed change as a difference against the current configuration and read the investigation that produced it, then apply or reject it. Applying re-verifies the change against the pipeline as it is now, and a running pipeline restarts to pick it up. A suggestion that no longer verifies is refused and stays pending, leaving the pipeline untouched.

package/build/dist/docs-index/6aa0a69f-53f3-4a1e-9b51-65a7a3ad7b2c.txt

@@ -0,0 +1,30 @@
+# Get parsed-query import state
+
+**GET** `/v1/integrations/{integrationId}/parsed-queries/import`
+
+**Operation ID**: `getParsedQueryImportStatus`
+**Summary**: Get parsed-query import state
+Says whether this vendor's parsed queries can be imported, whether the credential the import needs is saved, whether an import is already under way, and which integrations an import covers. Poll this while an import is running; what it imported is reported in the integration's activity log.
+
+## Tags
+- Integrations
+## Parameters
+
+- **integrationId** (required) - path
+  - Integration id
+  - Type: string
+
+## Responses
+
+### 200
+
+State retrieved
+
+- **Content-Type**: `application/json` / `ParsedQueryImportStatus`
+### 401
+
+Unauthorized
+
+### 404
+
+Not Found - Integration not found.

package/build/dist/docs-index/72109c2e-93fd-47b7-b172-96ae83304682.txt

@@ -0,0 +1,81 @@
+This page provides a comprehensive overview of the Grepr-supported integrations with observability platforms and cloud storage, and the features supported by those integrations.
+
+# Grepr supported vendor and storage integrations
+
+This page provides an overview of the observability platform and cloud storage integrations supported by the Grepr platform. This page also specifies the features supported by each integration, including whether it can be used as a source or a sink.
+
+> If you require an integration that Grepr does not support, contact <support@grepr.ai>.
+
+## Supported integrations: cloud storage
+
+Grepr supports Amazon S3 for storing, querying, and backfilling raw data. See [Host a Grepr data lake with the Amazon S3 integration](/integrations/aws-s3).
+
+## Supported integrations: AI agents \[#supported-ai-integrations]
+
+The following integrations support Grepr AI agents. None of them are a pipeline source or sink, so they do not appear in the source and sink tables on this page.
+
+| Integration | What it provides |
+| --- | --- |
+| LLM provider | The generative model an agent reasons with and the embedding model agent memory uses. |
+| MCP server | The tools of another system that an agent can call. |
+| Grepr Agent webhook | An endpoint that turns events from another system into investigations. |
+| Vector index | Storage for the agent memory search index. |
+
+To configure these, see [_](/integrations/llm), [_](/integrations/mcp), [_](/integrations/grepr-agent-webhooks), and [_](/ai-agents/memory#vector-index).
+
+Grepr adds integrations continuously. To get an agent connected to the provider you use, contact <support@grepr.ai>.
+
+## Supported integrations: observability platforms \[#supported-observability-integrations]
+
+A Grepr integration provides the configuration details needed to connect to an external system, such as an observability platform. Integrations support moving data into Grepr and between Grepr and external systems by enabling the creation of sources and sinks in your Grepr pipelines.
+
+Some integrations support the automatic creation of exceptions based on information returned by vendor tools. These exceptions ensure that Grepr passes through important messages without aggregation. For some integrations, this feature is available when the integration is enabled as a *cloud source*, which allows Grepr to read and process data from the external service. To learn more, see [Identify log events that should bypass aggregation](/integrations#passthrough-estimation)
+
+The following are the observability platform and tool integrations supported by Grepr as data sources and sinks:
+
+| Integration | As source | As sink | Exception parsing |
+| --- | --- | --- | --- |
+| Datadog | Yes | Yes | Yes. See [Enable Datadog selective reduction](/integrations/datadog#enable-selective-reduction). |
+| New Relic | Yes | Yes | Yes. See [Enable New Relic selective reduction](/integrations/new-relic#enable-selective-reduction). |
+| Splunk | HEC, HTTP | HEC only | No |
+| Google Cloud Platform | Yes | No \[^gcpsink] | Not applicable \[^gcpep] |
+| Grafana Cloud | Yes | Yes | No |
+| OpenTelemetry | Yes | Yes | Not applicable |
+| Sumo Logic | Yes | Yes | No |
+| Amazon S3 \[^awsstorage] | Yes | No | Not applicable |
+
+\[^gcpsink]: Although Grepr supports streaming data from GCP, you cannot use GCP as a sink. Instead, you configure a supported sink for the output from your Grepr pipeline. To learn more, see [Google Cloud Platform observability with Grepr](/integrations/gcp). \[^gcpep]: Because the exception parsing feature is configured as a separate step in your pipeline, support for this feature is based on the sink configured on the pipeline. \[^awsstorage]: The support mentioned in this table is for reading from arbitrary files in Amazon S3 and writing to files in arbitrary formats, such as JSON or plain text. To learn about using S3 as data lake storage, see [Host a Grepr data lake with the Amazon S3 integration](/integrations/aws-s3).
+
+## Frequently Asked Questions
+
+### Which observability platforms can I use as sources in Grepr?
+
+Grepr supports the following platforms as sources: Datadog, Splunk (HEC and HTTP), Google Cloud Platform, Grafana Cloud, New Relic, OpenTelemetry, Sumo Logic, and Amazon S3. Each platform provides different capabilities for ingesting data into Grepr pipelines.
+
+### Which observability platforms can I use as sinks in Grepr?
+
+Grepr supports the following platforms as sinks: Datadog, Splunk (HEC only, not HTTP), Grafana Cloud, New Relic, and OpenTelemetry. Note that GCP and Amazon S3 have specific limitations: GCP cannot be used as a sink, and S3 supports arbitrary format writing but not Iceberg data lake functionality.
+
+### What is exception parsing in Grepr integrations?
+
+Exception parsing is a feature that automatically creates exceptions from information returned by vendor tools, ensuring that important messages pass through without aggregation. This feature is supported by Datadog and Splunk integrations, and is available when the integration is enabled as a cloud source.
+
+### Does Grepr support OpenTelemetry?
+
+Yes, Grepr supports OpenTelemetry as both a source and a sink. You can use the OpenTelemetry Protocol (OTLP) to ingest data from compatible collectors or output processed logs to platforms like Grafana Cloud that accept OTLP data.
+
+### What is the difference between Splunk HEC and HTTP support?
+
+Splunk HEC (HTTP Event Collector) is supported for both source (reading) and sink (writing) operations. Splunk HTTP support is available as a source only. When configuring a Splunk sink, use the HEC integration for data output.
+
+### Can I use Google Cloud Platform (GCP) as a data sink?
+
+No, GCP cannot be used as a sink in Grepr pipelines. While Grepr supports streaming logs from GCP sources, for data output you must configure a different supported sink such as Datadog, Splunk, New Relic, Grafana Cloud, or OpenTelemetry.
+
+### How does exception parsing work with GCP integrations?
+
+Exception parsing for GCP is not applicable as a direct feature. Instead, the exception parsing feature is configured as a separate step in your pipeline, and support is based on the sink you configure for your pipeline output.
+
+### What cloud storage options does Grepr support?
+
+Grepr supports Amazon S3 for storing and querying raw data in the Grepr data lake. You can use either a Grepr-hosted S3 integration or configure your own S3 bucket in your AWS account. S3 can also be used as a source for reading arbitrary files in any format.

package/build/dist/docs-index/764e9835-fd28-4d02-b75c-5f188e146866.txt

@@ -0,0 +1,51 @@
+# Submit a webhook event
+
+**POST** `/v1/integrations/webhooks/{id}/events`
+
+**Operation ID**: `postEvent`
+**Summary**: Submit a webhook event
+Accepts one JSON event from the sending system and starts an investigation on each target agent of the integration. The org is taken from the Grepr API key and the integration id from the path. Returns 202 with the started investigation ids. Retries after a 5xx may start duplicate investigations.
+
+## Tags
+- Webhook Events
+## Parameters
+
+- **id** (required) - path
+  - The webhook integration id.
+  - Type: string
+
+## Request Body
+
+**Content-Type**: `application/json`
+
+**Schema**: string
+
+## Responses
+
+### 202
+
+Investigation(s) started
+
+### 400
+
+Body is not valid JSON
+
+### 401
+
+API key is invalid
+
+### 404
+
+No such webhook integration
+
+### 409
+
+The integration has no live target agent to start
+
+### 413
+
+Body exceeds the size limit
+
+### 503
+
+At least one target agent could not be started for a transient reason; retry

package/build/dist/docs-index/7ec228ac-0e96-45b4-a651-e24c23f6794d.txt

@@ -0,0 +1,40 @@
+# Pause or resume an agent's pipeline subscription
+
+**PUT** `/v1/agents/{id}/pipelines/{jobId}/state`
+
+**Operation ID**: `setPipelineState`
+**Summary**: Pause or resume an agent's pipeline subscription
+Sets one subscription to PAUSED or ACTIVE. While paused, new signals from the pipeline are dropped for this agent, and the pipeline keeps marking new patterns as sent. Investigations already queued still run. The running pipeline is not restarted.
+
+## Tags
+- Agents
+## Parameters
+
+- **id** (required) - path
+  - Type: string
+- **jobId** (required) - path
+  - Type: string
+
+## Request Body
+
+**Content-Type**: `application/json`
+
+**Schema**: `StateChangeRequest`
+
+## Responses
+
+### 204
+
+State set (or already set)
+
+### 400
+
+The state is not ACTIVE or PAUSED
+
+### 401
+
+Unauthorized
+
+### 404
+
+Agent not found, or not subscribed to the pipeline

package/build/dist/docs-index/894b5f96-17a7-4431-b546-d91bde9df59a.txt

@@ -0,0 +1,248 @@
+Learn how to configure how Grepr integrates with observability platforms and storage systems to support data ingestion, processing, and output in your pipelines.
+
+# Configure how Grepr integrates with observability platforms and cloud storage
+
+To support data ingestion and data output for your Grepr pipelines, you connect Grepr to external observability platforms and storage systems. To support these connections, the Grepr platform uses *integrations*. A Grepr integration provides the configuration details to connect to an external system, enabling data exchange between Grepr and that system.
+
+After configuring an integration, you can use it in your Grepr pipelines to create *sources* to ingest data from agents and collectors, such as FluentD or the OpenTelemetry collector, and *sinks* to send data to an observability platform or storage.
+
+You can use the Grepr UI or the REST API to create and manage integrations. To use the UI, see [Manage integrations in the Grepr UI](#manage-integrations-in-ui). To use the API, see the documentation for each [supported integration](#supported-integrations).
+
+## Integration types
+
+The Grepr platform includes the following integration types:
+
+* Observability platform integrations: Connections to monitoring, logging, and APM platforms, such as Datadog, Splunk, New Relic, and Sumo Logic.
+* Cloud storage integrations: Connections to cloud storage. The Grepr data lake uses cloud storage to store your raw data and metadata.
+* AI integrations: Connections that Grepr AI agents use, covering the model providers they reason with, the MCP servers they call, the webhook endpoints that trigger them, and the vector indexes that store their memories. See [Supported AI integrations](#ai-integrations).
+
+Observability platform and cloud storage integrations become the sources and sinks of your pipelines. AI integrations are used by AI agents instead, so they are not selectable as a pipeline source or sink.
+
+## Supported platform and storage integrations \[#supported-integrations]
+
+The Grepr platform includes the following integrations. For details on configuring and using an integration, refer to the linked documentation page. For a complete list of supported integrations, supported functionality, and details on vendor-specific capabilities with some integrations, see [Grepr supported vendor and storage integrations](/integrations/support-matrix).
+
+### Datadog
+
+The Datadog integration connects to the Datadog observability platform and supports sourcing data from several Datadog-compatible collectors and sending processed data to Datadog.
+
+See [Configure Datadog connections with a Grepr integration](/integrations/datadog).
+
+### New Relic
+
+The New Relic integration connects to New Relic's observability platform. Use this integration to create sources that retrieve log data from New Relic collectors and sinks that send processed data to New Relic for monitoring and analysis.
+
+See [Configure New Relic connections with a Grepr integration](/integrations/new-relic).
+
+### Splunk
+
+The Splunk integration provides connectivity to Splunk through Splunk's HTTP Event Collector (HEC) or S2S over HTTP. This integration supports reading data from Splunk collectors and writing data to Splunk indexes.
+
+See [Configure Splunk connections with a Grepr integration](/integrations/splunk).
+
+### Sumo Logic
+
+The Sumo Logic integration connects to Sumo Logic's cloud-based log management and monitoring platform using a Sumo Logic HTTP Source. You can use the integration to create sources that ingest data from Sumo Logic collectors and sinks that send processed data to Sumo Logic.
+
+See [Configure Sumo Logic connections with a Grepr integration](/integrations/sumo-logic).
+
+### OpenTelemetry
+
+The Grepr OpenTelemetry integration lets you ingest logs and Application Performance Monitoring (APM) data into Grepr from a collector that supports the OpenTelemetry Protocol over HTTP, or OTLP/HTTP, process them with a Grepr pipeline, and then send the processed data to any observability vendor that accepts OTLP/HTTP requests.
+
+See [Configure connections to OpenTelemetry compatible platforms](/integrations/open-telemetry).
+
+### Grafana Cloud
+
+You can configure Grepr's OpenTelemetry integration to connect with Grafana Cloud using the OpenTelemetry Protocol (OTLP). Use an OpenTelemetry integration to create sources that ingest data from OTLP-compatible collectors and sinks that send processed log data to Grafana Cloud.
+
+See [Configure Grafana Cloud connections with a Grepr integration](/integrations/grafana).
+
+### Amazon CloudWatch
+
+You can configure Grepr's OpenTelemetry integration to connect with Amazon CloudWatch using the OpenTelemetry Protocol (OTLP). Use an OpenTelemetry integration to create sources that ingest data from OTLP-compatible collectors and sinks that send processed log data to a CloudWatch log group.
+
+See [Configure Amazon CloudWatch connections with a Grepr integration](/integrations/cloudwatch).
+
+### Google Cloud Platform (GCP)
+
+The GCP integration as a source enables you to stream logs from Google Cloud services to Grepr for processing and analysis, and then forward the processed logs to any sink created using a Grepr-supported integration, such as Datadog, Splunk, or New Relic.
+
+See [Google Cloud Platform observability with Grepr](/integrations/gcp).
+
+### Cloud storage
+
+The Grepr data lake uses Amazon S3 to store, manage, and support querying the raw data from your Grepr pipelines. Depending on your requirements, you can choose from two S3 integrations: a Grepr-hosted integration, which uses a Grepr-managed S3 bucket, and an integration that uses an S3 bucket in your account. Both integrations provide secure, managed, and efficient storage for your data, along with an optimized query interface.
+
+To configure the Grepr-hosted integration, you only need to assign a name to the integration. The Grepr platform manages the S3 bucket, including its deployment and configuration.
+
+Using the integration with your own S3 bucket requires that you deploy and configure an S3 bucket in your AWS account, but it provides more control over your data. See [Host a Grepr data lake with the Amazon S3 integration](/integrations/aws-s3).
+
+## Supported AI integrations \[#ai-integrations]
+
+The following integrations support Grepr AI agents. They appear on the **Integrations** page only when AI agents are enabled for your organization. To turn on AI agents, contact <support@grepr.ai>. To learn what AI agents do, see [_](/ai-agents).
+
+### LLM providers
+
+An LLM integration holds the credentials for a large language model provider. Grepr AI agents use generative models for reasoning and embedding models for memories.
+
+See [_](/integrations/llm).
+
+### MCP servers
+
+An MCP integration connects Grepr to a MCP server run by another system, so an agent can call that system's tools during an investigation. You set each integration's server URL, so you can point one at a self-hosted or regional endpoint.
+
+See [_](/integrations/mcp).
+
+### Grepr Agent webhooks
+
+A Grepr Agent integration is a webhook endpoint that turns events from another system, such as an alerting platform or a Kubernetes event forwarder, into AI agent investigations.
+
+See [_](/integrations/grepr-agent-webhooks).
+
+### Vector indexes
+
+A vector index integration stores the search index for agent memory, which is what lets an agent find past investigations that reached a similar conclusion. You create one in the **S3 Vector Index** section of the **Integrations** page.
+
+See [_](/ai-agents/memory#vector-index).
+
+## Manage integrations in the Grepr UI \[#manage-integrations-in-ui]
+
+The **Integrations** page displays your integrations as cards, organized by observability vendor integrations and storage integrations. In each section, cards are ordered by recent activity, with the most active integrations appearing first.
+
+In addition to the integration name and its type, for example, a Datadog integration, if the integration is assigned to one or more teams, the team names appear in the header of the card.
+
+You can get a visual overview of the health and usage of your integrations using the charts included on each integration card. If an integration has recent activity, such as requests received from agents by a vendor integration or the amount of data written to a storage integration, a time-series chart of that activity is shown on the card.
+
+* Observability vendor integrations display requests received from agents over the last 30 minutes, color-coded by HTTP status code.
+
+  * To view more detailed metrics or more details about a pipeline that uses the integration, select it from the **Pipelines** menu.
+
+* Storage integrations display data written to the integration over the last 24 hours, broken down by dataset.
+
+  * To view and query a dataset stored on a storage integration, select it from the **Datasets** menu.
+
+To view more details about the metrics in either chart type, hover over any point in the chart to see a tooltip with the value and timestamp for that point.
+
+### Add an integration
+
+To create an integration, click **Add new** next to the section heading for the type you want to add. To learn how to create and configure specific integrations, see the documentation for each [supported integration](#supported-integrations).
+
+### Edit an integration
+
+To edit an integration, click the three-dot menu on the integration card and select **Edit**. Update the fields in the dialog and click **Save**.
+
+### Delete an integration
+
+To delete an integration, click the three-dot menu on the integration card and select **Delete**. Confirm the deletion in the dialog that appears.
+
+### Identify log events that should bypass aggregation \[#passthrough-estimation]
+
+When you create an integration with an observability vendor that supports *exception parsing*, Grepr automatically parses queries used by monitors, dashboards, or alerts in your observability vendor platform. You can use this list of queries to identify log messages that should be treated as *exceptions* to log reduction in Grepr pipelines. In other words, messages that should bypass aggregation to ensure that critical alerts and dashboards continue to work as expected. To help with identifying exceptions, the Grepr UI displays a *passthrough percentage* estimate for each query. This estimate is the percentage of events, over a configurable time window, that would bypass aggregation.
+
+You can also choose to automatically add and remove exceptions by enabling **Auto-sync exceptions** when you add the integration to your pipelines. To learn more about enabling and using auto-sync when you create or edit a pipeline, see [Prevent aggregation of messages used in your observability platform](/transforms/reducer/exceptions#vendor-exceptions).
+
+If an integration does not support exception parsing, the **Parsed Alerts** button on the integration card is disabled. See [Supported integrations: observability platforms](/integrations/support-matrix#supported-observability-integrations).
+
+To view the log queries parsed from an integration and configure passthrough estimation:
+
+1. On the **Integrations** page, on the card for a vendor integration that supports query parsing, click **Parsed Alerts**.
+
+   The **Parsed alert queries** dialog displays a table with the following columns:
+
+   * **Id**: The unique identifier for this alert.
+   * **Name**: The alert or dashboard name from your vendor.
+   * **Exception Type**: The type of vendor resource the query came from, such as a monitor or dashboard widget.
+   * **Query**: The log query extracted from the alert or dashboard.
+   * **Passthrough %**: The percentage of raw logs in your configured dataset that match this query. This value is displayed only if you've configured passthrough estimation.
+   * **Last Updated**: When the passthrough percentage was last calculated. Hover over the value to see the exact date and time.
+
+   You can filter the table by name or query text and filter by exception type using the multi-select filter in the **Exception Type** column. To manage which columns are visible, click the **Manage columns** icon in the upper-right corner of the table.
+
+2. To configure passthrough estimation and view the percentage of logs that would bypass aggregation for each query, click **Configure Passthrough Estimation**.
+
+   The **Passthrough Estimation Configuration** dialog lists the datasets that pipelines using the integration write to. Each row shows whether passthrough estimation is configured for that dataset and which pipelines use it.
+
+   > When you configure passthrough estimation for a dataset, it applies to all integrations or pipelines that use that dataset as a sink.
+
+3. Expand the row for the dataset you want to configure.
+
+4. Under **Filter Query (Optional)**, select your preferred query syntax and enter a query to filter for logs to include in the estimation analysis. Use this field when your dataset contains logs from multiple sources, and you want Grepr to use only the logs relevant to this integration. Leave this field empty to include all logs in the dataset.
+
+5. In the **Lookback Duration** menu, select the time window for calculating percentages. Options range from 15 minutes to 24 hours. A shorter window scans less data, reducing costs, but may not be representative if your log patterns vary throughout the day. A longer window provides more representative results but increases the cost of the analysis queries.
+
+6. In the **Refresh Period** menu, select how often Grepr recomputes each estimation for this dataset. Options range from 1 hour to 30 days, with a default of 7 days. A shorter period uses more recent logs to calculate estimates, resulting in more up-to-date values, but increases query load on the data lake.
+
+7. In the **Log Limit** field, enter the maximum number of logs to scan per estimation run. The default is 10,000,000. Larger limits provide more representative results, but increase the cost of each estimation query.
+
+8. To save a new configuration, click **Enable**. To save edits to an existing configuration, click **Save changes**.
+
+Grepr's impact estimation cycle runs once an hour for any datasets due for refresh, based on each dataset's **Refresh Period**. New or recently changed queries are included in the next cycle. A first estimate typically appears within an hour, though it might take longer if a large number of queries are queued for processing.
+
+To stop estimating for a dataset, expand its row and click **Disable estimation**. The dataset remains in the list as **Not configured** so you can re-enable estimation later.
+
+### Interpret passthrough percentages
+
+> Although two queries might use the same log events, their estimates will be equal. Additionally, the passthrough rate remains constant and is not the sum of the estimates. For example, if you enable exceptions for two queries that use the same log events, the passthrough rate doesn't double, but remains equal to the rate when only one exception is enabled.
+
+The **Passthrough %** value for a query shows what fraction of your raw logs that alert would require to pass through without aggregation. Use these values to evaluate the impact of adding each alert as a pipeline exception:
+
+A percentage less than 1% is considered low, and an exception should have minimal impact on aggregation efficiency and storage.
+
+You should review carefully any percentage above 1% before creating an exception for the query.
+
+A dash (—) in the **Passthrough %** column indicates that no estimate is available yet, either because passthrough estimation is not configured, or because Grepr hasn't finished calculating the estimate. If passthrough estimation is configured, the first estimate typically appears within an hour, and later refreshes occur based on the dataset's **Refresh Period**.
+
+The **Passthrough Estimation Configuration** dialog also includes the **Recent Activity** table at the bottom. This section shows the most recent log events related to exception parsing, giving you visibility into recent integration activity without leaving the dialog. To view the complete log history for the integration, click **View all logs** to go to the **System Logs** page, pre-filtered to show all activity for the selected integration.
+
+### Configure passthrough estimation from a pipeline
+
+You can also configure passthrough estimation directly from a pipeline. On the pipeline details page, in the left-hand navigation menu, click **Exceptions**. In the **Actions** column for an **Avoid impacting dashboards/alerts** exception, click the **⋯** menu and select **Configure estimations** to open a dialog that includes all datasets configured as sinks for the pipeline. Any configuration changes you make to the dataset apply to every other integration or pipeline that populates that dataset.
+
+To have Grepr recompute impact percentages during the next impact estimation cycle, click the **⋯** menu and select **Reset estimations** to clear the cached impact percentages for the datasets configured as sinks for the pipeline. Use this when you've changed alert queries in your observability vendor and want updated estimates without waiting for the next scheduled refresh.
+
+## Limitations \[#limitations]
+
+Grepr might split log events over 900KB, causing them to lose their original structured format. Each split event includes a common `grepr.splitOriginId` attribute if you need to reconstruct the original message.
+
+## Frequently Asked Questions
+
+### What is a Grepr integration?
+
+A Grepr integration provides the configuration details needed to connect Grepr to an external system, such as an observability platform or cloud storage. Integrations enable data exchange between Grepr and external systems, allowing you to create sources for data ingestion and sinks for data output in your pipelines.
+
+### What types of integrations does Grepr support?
+
+Grepr supports two integration types: observability platform integrations (connections to monitoring, logging, and APM platforms like Datadog, Splunk, New Relic, and Sumo Logic) and cloud storage integrations (connections to cloud storage for the Grepr data lake).
+
+### What is a source in a Grepr pipeline?
+
+A source in a Grepr pipeline is an operator that ingests data from an external system or agent. Sources use integrations to connect to observability platforms or collectors like FluentD or OpenTelemetry to pull data into Grepr for processing.
+
+### What is a sink in a Grepr pipeline?
+
+A sink in a Grepr pipeline is an operator that outputs processed data to an external system. Sinks use integrations to send Grepr-processed logs to observability platforms, data lakes, or other storage systems based on your pipeline configuration.
+
+### Can I use multiple integrations in a single pipeline?
+
+Yes, you can configure pipelines with multiple sources to ingest data from different platforms and multiple sinks to send processed data to different destinations. This flexibility allows you to build complex multi-source, multi-destination data processing workflows.
+
+### Which observability platforms does Grepr support?
+
+Grepr supports integrations with Datadog, Splunk, New Relic, Sumo Logic, Grafana Cloud, and Google Cloud Platform (GCP). Each integration enables different source and sink capabilities depending on the platform's features and capabilities.
+
+### How do I configure a Grepr integration?
+
+To configure an integration, you need to provide connection details specific to your external system, such as API keys, tokens, endpoints, or credentials. The specific steps vary by integration type. Detailed instructions for each integration are available in the platform-specific documentation pages.
+
+### What is the Grepr data lake integration?
+
+The Grepr data lake uses Amazon S3 to store raw log data. You can configure either a Grepr-hosted integration (using a Grepr-managed S3 bucket) where you only provide a name, or an integration with your own AWS account (requiring you to configure and manage the S3 bucket yourself for more control).
+
+### What happens to logs older than 48 hours from external sources?
+
+Grepr might drop incoming data from external integration sources with timestamps older than 48 hours. This limitation helps optimize storage and processing while allowing you to retain raw logs in the data lake for longer-term analysis.
+
+### What happens when a log event is larger than 900KB?
+
+If a log event exceeds 900KB, Grepr might split it into smaller events, which can cause them to lose their original structured format. Each split event includes a common 'grepr.splitOriginId' attribute that you can use to reconstruct the original message from its component parts.