# Authentication Source: https://docs.wildmoose.ai/api-reference/authentication Authenticate with the Wild Moose API using JWT tokens All API requests must include a valid JWT token in the `Authorization` header. ## Using your token Include the token as a Bearer token in every request: ```bash theme={null} Authorization: Bearer YOUR_TOKEN ``` Keep your API tokens secure. Never commit them to source control or expose them in client-side code. ## Error responses | Status code | Meaning | | -------------------- | ----------------------------------------------- | | **401 Unauthorized** | Token is missing, expired, or invalid | | **403 Forbidden** | API access is not enabled for your organization | If you receive a `401` error, verify that your token is valid and has not expired. If you receive a `403` error, contact your Wild Moose account administrator to enable API access. # Batch execute Source: https://docs.wildmoose.ai/api-reference/endpoint/batch-execute POST /playbook/execution/batch Executes playbooks for multiple production issues in a single request. Each item in the inputList can either provide a message link or details. If bookName is specified for an item, the playbook is identified by name and messageLink/title are optional. Maximum 10 items per batch. # Execute a playbook Source: https://docs.wildmoose.ai/api-reference/endpoint/execute-playbook POST /playbook/execution Executes a playbook for a single point in time when a production issue took place. The request can either provide a message link to a Slack message describing the issue, or provide its details directly. Alternatively, if bookName is specified, the playbook is identified by name and messageLink/title are optional. # List playbooks Source: https://docs.wildmoose.ai/api-reference/endpoint/list-playbooks GET /playbook Returns a list of all available playbooks for the organization, including their names, associated monitor names, and any required attributes. # API overview Source: https://docs.wildmoose.ai/api-reference/introduction Trigger investigations programmatically with the Wild Moose Execution API The Wild Moose Execution API lets you trigger investigations programmatically - from CI/CD pipelines, custom alerting systems, or any tool that can make HTTP requests. You don't need to memorize the API. The [Moose Builder](/features/builder) already knows every endpoint and can help you integrate Wild Moose into your workflows. ## Base URL ``` https://api.wildmoose.ai ``` ## What you can do Run an investigation for a single production issue. Investigate multiple issues in a single request. Retrieve all available playbooks for your organization. ## Authentication All API requests require a Bearer token (JWT) in the `Authorization` header. See [Authentication](/api-reference/authentication) for details on obtaining and using tokens. ```bash theme={null} curl -X POST https://api.wildmoose.ai/playbook/execution \ -H "Authorization: Bearer YOUR_TOKEN" \ -H "Content-Type: application/json" \ -d '{"bookName": "perf-checks", "time": "2025-01-15T10:30:00Z"}' ``` ## Response format All endpoints return JSON. Successful investigation responses include: * **`highlights`** - AI-generated root cause analysis and summary. * **`gadgetsHighlights`** - per-action findings and key insights. * **`actionResults`** - structured results from each action with links to source tools. * **`actionableMitigations`** - structured remediation steps with all the parameters needed to execute each mitigation (automatically, even). When you pass a `channelId`, Wild Moose also posts the enrichment results to the specified channel and returns an `enrichmentLink` in the response. # Key concepts Source: https://docs.wildmoose.ai/concepts Understand the building blocks of Wild Moose You don't need to memorize any of this. The [Moose Builder](/features/builder) already knows all these concepts and will guide you through them as needed. ## Moose Builder The **Moose Builder** is your primary interface for working with Wild Moose. It's an AI agent that guides you through creating, testing, and refining debugging agents conversationally - no need to learn YAML or configuration syntax. Just describe what you want to investigate and the Builder handles the rest. [Learn more](/features/builder). ## Debugging agents Wild Moose uses specialized **debugging agents** to investigate production incidents. Each agent is a focused investigator that knows how to query your observability tools, analyze the results, and surface root cause analysis - in seconds. An orchestrator dynamically selects and coordinates agents based on the alert context. Multiple agents can run in parallel, each investigating a different angle. Agent behavior is configured through **playbooks** - YAML files that define what to investigate. The terms agent and playbook are used interchangeably in Wild Moose. Each agent's playbook contains: * **Monitor patterns** - alert patterns that trigger the agent automatically. * **Required attributes** - parameters like `environment`, `cluster`, or `host` that scope the investigation. * **Actions** - the individual steps the agent runs during the investigation. * **Mitigation tools** - remediation steps surfaced after the investigation completes. Agents are lightweight, cost-effective, and scalable - designed to run on every alert, not just critical ones. ## Actions **Actions** are the individual steps inside an agent's playbook. Each action queries one of your connected tools to gather a specific piece of evidence. Examples of actions: * Query CPU and memory metrics from Datadog * Search application logs for error patterns * Check recent deployments in your CI/CD system * Look up traces for slow endpoints Actions run in parallel when possible, so investigations complete in seconds. ## Enrichments An **enrichment** is the output of a completed investigation - a structured summary posted back as a threaded reply on the original alert. An enrichment typically includes: * **Root cause analysis** - an AI-generated summary of what went wrong and why. * **Key findings** - highlights from each action that ran (e.g., "CPU at 95% on web-server-01"). * **Links** - direct links to the relevant dashboards, log queries, or traces in your observability tools. * **Suggested mitigations** - actionable next steps to resolve the issue. ## Feedback Wild Moose gets smarter with every incident. After an investigation completes, your team can provide feedback on the results - flagging what was useful, what was missing, or what could be improved. This feedback feeds directly into the system, helping agents refine their investigations over time and adapt to your team's specific environment and workflows. ## Alert matching When an alert arrives in a monitored channel, the orchestrator analyzes the alert context and dynamically coordinates the right debugging agents. The system can match alerts based on multiple signals and run multiple agents in parallel to investigate different angles simultaneously. If a match is found, Wild Moose automatically kicks off the investigation. Investigations can also be triggered programmatically via the [Execution API](/api-reference/introduction). Your AI guide for creating and testing agents. Learn about agents and how investigations are structured. # Debugging agents Source: https://docs.wildmoose.ai/features/agents How Wild Moose investigates production incidents Wild Moose uses specialized debugging agents to investigate production incidents. When an alert fires, an orchestrator dynamically selects and coordinates the right agents - each one a focused investigator that knows how to query your tools and analyze the results. Investigations complete in seconds, not minutes. Agent behavior is configured through **playbooks** - YAML files that define what each agent should investigate. You don't need to write these by hand - the [Moose Builder](/features/builder) creates and tests them for you. ## How agents work A monitoring tool posts an alert to one of your monitored channels, or an investigation is triggered via the API. The orchestrator analyzes the alert context and dynamically coordinates the right debugging agents. Multiple agents can be selected for a single alert. Each agent queries your connected tools - metrics, logs, traces, deployments - gathering evidence simultaneously from different angles. Data collection is deterministic and parallel; AI is used only to synthesize the results. The findings are combined into a structured enrichment with root cause analysis, key findings, and suggested mitigations, posted as a threaded reply - in seconds. ## Why agents are fast and cheap Each agent combines deterministic automation with AI-powered analysis. The automation layer handles all data collection - which tools to call, in what order, with what parameters. The AI layer analyzes and synthesizes the output into a clear conclusion. No LLM-driven planning or retry loops, just parallel data gathering followed by a single synthesis pass. This architecture means agents are: * **Fast** - investigations complete in seconds because tool calls run in parallel * **Cost-effective** - lightweight enough to run on every alert, not just critical ones * **Reliable** - deterministic data collection means predictable, debuggable behavior * **Transparent** - every step is visible and configurable ## Building agents The [Moose Builder](/features/builder) is the fastest way to create agents. It can: * Infer investigation workflows from your historical incidents * Build agents conversationally from your team's debugging knowledge * Test agents against real past issues before they go live You can also configure agents manually through playbooks. ## Configuring agents with playbooks Each agent's behavior is defined by a playbook - a YAML configuration that specifies what to investigate and how. Workflows are open, transparent, and fully configurable. Actions are the individual investigation steps. Each action queries one of your connected tools - metrics, logs, traces, deployments - to gather evidence. Actions run in parallel when possible to keep investigations fast. A contextual hint that guides the agent's AI when analyzing results. The tip tells the agent what this investigation is trying to accomplish, helping it produce more relevant root cause analysis and recommendations. Remediation suggestions that are surfaced after an investigation completes. Each mitigation tool can be either: * A **link** to an external tool (e.g., a runbook, a scaling dashboard, a rollback pipeline) * An **action** that can be executed directly You can mark a mitigation tool as `displayAlways` to show it regardless of the investigation outcome. Title patterns that map incoming alerts to this agent. Patterns support `{{placeholder}}` wildcards for flexible matching. For example, the pattern `Instance {{host}} CPU is >{{threshold}}%` would match alerts like *"Instance web-01 CPU is >90%"* and automatically extract `host` and `threshold` as attributes. Attributes that scope the investigation to the right context. Common examples include `environment`, `cluster`, `host`, or `service`. Attributes can be extracted automatically from the alert via monitor patterns, or provided manually when triggering an investigation. Key-value pairs that get substituted into action arguments using `{{variableName}}` syntax, allowing you to reuse the same actions with different configurations. ## Agent capabilities Beyond standard investigation, agents can: * **Detect anomalies** - identify unusual patterns in metrics and logs that may not have triggered alerts themselves * **Identify suspicious services** - pinpoint the service or component most likely responsible for the incident * **Suggest mitigations** - recommend specific remediation steps based on the investigation findings * **Deduplicate alerts** - recognize when multiple alerts are symptoms of the same underlying issue * **Learn from feedback** - improve investigation quality over time based on your team's input ## How investigations are triggered When an alert arrives in a monitored channel, the orchestrator analyzes the alert context and dynamically coordinates the right debugging agents. Multiple agents can run in parallel for the same alert, each investigating a different angle based on what the system finds. Investigations can also be triggered: * Manually via commands in Slack or Teams * Programmatically via the [Execution API](/api-reference/endpoint/execute-playbook) ## Best practices Let the [Moose Builder](/features/builder) create your first agents. It will test them against historical incidents and refine them for you. Write monitor patterns that are specific enough to avoid false matches but flexible enough to cover alert variations. # Alert deduplication Source: https://docs.wildmoose.ai/features/alert-deduplication Treat alert bursts as a single event, not a flood When something breaks in production, you rarely get just one alert. A single root cause can trigger dozens of related alerts across services, regions, and monitoring tools. Wild Moose recognizes these bursts and treats them as a single global event. ## Why deduplication matters Without deduplication, each alert in a burst would trigger its own investigation - hammering your observability APIs with redundant queries and flooding your channels with duplicate findings. Wild Moose avoids this by: * **Grouping related alerts** into a single event * **Running one coordinated investigation** instead of many redundant ones * **Producing a unified analysis** that considers all the related signals together # Alert enrichment Source: https://docs.wildmoose.ai/features/alert-enrichment Automatically gather context the moment an alert fires When a production alert fires, the first thing your team does is scramble for context - pulling up dashboards, searching logs, checking recent deploys. Wild Moose does all of this automatically, posting the results as a threaded reply within seconds. ## Automatic enrichment Wild Moose continuously monitors your channels and automatically triggers investigations when it detects something worth looking into - alerts, incidents, and other signals. Here's what happens: 1. **Matches** the event to the right investigation workflow. 2. **Extracts** key attributes (service name, environment, host, etc.) from the context. 3. **Runs** actions against your connected observability tools. 4. **Posts** a structured enrichment thread with findings, root cause analysis, and links to relevant dashboards. Automatic enrichment runs without any human intervention. Your on-call engineer sees the event and the investigation results at the same time. ## On-demand enrichment You can also trigger investigations manually using commands in Slack or Teams, or programmatically via the [Execution API](/api-reference/introduction). ## What's in an enrichment? A typical enrichment thread includes: | Section | Description | | ------------------------- | ---------------------------------------------------------- | | **Root cause analysis** | AI-generated summary of what went wrong and why | | **Action results** | Key findings from each action (metrics, logs, traces) | | **Dashboard links** | Direct links to relevant views in your observability tools | | **Suggested mitigations** | Actionable steps to resolve the issue | Enrichment results link directly to the source tool (e.g., a Datadog dashboard or Grafana panel) so your team can dive deeper when needed. # Moose Builder Source: https://docs.wildmoose.ai/features/builder Your AI guide for creating, testing, and refining debugging agents The Moose Builder is your primary interface for working with Wild Moose. Instead of learning YAML syntax, memorizing configuration options, or reading through documentation - just tell the Builder what you want to investigate and it handles the rest. To get started immediately, just ask the Builder: *"help me improve our autonomous-RCA coverage"*. It will guide you through setting up and evaluating your own apparatus of debugging agents. ## What the Builder does The Builder is an AI agent that knows Wild Moose inside and out - the [key concepts](/concepts), the [API](/api-reference/introduction), every integration, every configuration option. It acts as your expert guide, so you don't have to memorize any of it. Describe what you want to investigate in plain language. The Builder translates your intent into fully configured debugging agents. The Builder stress-tests your agents against historical issues to verify they find the right root causes before they go live. If you have enough historical data, the Builder can infer investigation workflows automatically - surfacing the debugging patterns your team follows but may never have documented. Review test results, adjust agent behavior, and re-test in a tight feedback loop. The Builder learns what works for your environment. ## Meet you where you're at The Builder adapts to your starting point: * **Rich historical data?** The Builder analyzes your past incidents and proposes agents automatically, using the objective truth from hundreds of real events to build investigation workflows. * **Some context but gaps?** The Builder combines what it can infer from your tools with your team's input to fill in the blanks. * **Starting from scratch?** Walk the Builder through your debugging process step by step, and it builds agents as you go. Either way, agents are built as code - open, transparent, and fully configurable. Nothing is a black box. ## Test-driven by design Every agent the Builder creates goes through testing before it's deployed: 1. **Historical replay** - the Builder runs your agent against past incidents to verify it surfaces the right findings 2. **Test cases** - each replay becomes a test case, so future changes don't break what already works 3. **Confidence scoring** - you see exactly how well an agent performs before it handles live alerts This test-driven approach means your agents are reliable and predictable from day one. ## Getting started with the Builder The fastest way to start is to just ask: * *"Help me set up RCA for our 5xx error alerts"* * *"What's the best way to investigate high latency on our checkout service?"* * *"Can you analyze our last 2 weeks of incidents and suggest agents?"* The Builder will guide you from there. No prerequisites, no required reading. # Communication management Source: https://docs.wildmoose.ai/features/communication-management Control who sees what during investigations Wild Moose gives you fine-grained control over how investigation results are communicated. You decide which channels are monitored, what gets enriched, and who sees the results. ## Channel monitoring Configure which channels Wild Moose watches for alerts and incidents. You can monitor: * Dedicated alerting channels (e.g., #production-alerts) * Incident management channels * Specific channels per team or service You can add or remove monitored channels at any time without affecting existing investigations. ## Enrichment controls Not every alert needs the same level of investigation. You can configure: * **Which alerts get enriched** - filter by alert source, severity, or pattern * **What level of detail** - control how much context agents gather * **Where results are posted** - route enrichments to specific channels or threads # Suggested mitigations Source: https://docs.wildmoose.ai/features/mitigations Actionable remediation steps delivered with every investigation After every investigation, Wild Moose delivers suggested mitigations - specific, actionable steps your team can take to resolve the incident. These aren't generic suggestions; they're tailored to what the agents actually found during the investigation. ## How mitigations work When an investigation completes, agents analyze the gathered evidence and recommend remediation steps. Each mitigation includes: * **What to do** - a clear description of the remediation action * **Where to do it** - direct links to the relevant tool, dashboard, or pipeline * **Parameters** - all the context needed to execute the mitigation (service name, environment, threshold values, etc.) ## Types of mitigations Direct links to runbooks, scaling dashboards, rollback pipelines, or other tools your team uses for remediation. These open in the right context so your team doesn't have to hunt for the right page. Actions that can be triggered directly from the investigation results. These range from simple operations like restarting a service to more complex workflows like rolling back a deployment. Some mitigations are relevant regardless of the investigation outcome. You can mark these as `displayAlways` to ensure they're always surfaced - useful for standard operating procedures or escalation paths. ## From suggestion to auto-fix Wild Moose mitigations exist on a spectrum of automation: 1. **Suggested** - the agent recommends a mitigation and links to the relevant tool 2. **One-click** - the mitigation can be executed directly from the investigation results 3. **Automatic** - for well-understood scenarios, agents can execute mitigations automatically Your team controls where each mitigation sits on this spectrum. Start with suggestions and gradually increase automation as confidence grows. Mitigations are configured as part of each agent's playbook. See [Debugging agents](/features/agents) for details on how to set them up. # Welcome to Wild Moose Source: https://docs.wildmoose.ai/index The AI SRE for dynamic environments Wild Moose is an always-on, AI first responder that executes your best debugging practices the moment something breaks. It codifies tribal knowledge to gather context across fragmented observability tools, delivering evidence-backed root causes and recommended next actions in seconds. **Just get started and learn on the go.** Tell the Moose Builder *"help me improve our autonomous-RCA coverage"*, and it will guide you through setting up and evaluating your own apparatus of debugging agents. This process is short and rewarding - with any luck, your moose will start finding root causes before you take your first bathroom break. ## Why Wild Moose? Wild Moose automatically gathers and analyzes logs, metrics, and code to deliver explainable root cause summaries - in seconds, not minutes. Build an army of agents tuned to your specific investigative workflows, encoding the muscle-memory knowledge your team has built over years. Creation happens collaboratively with your favorite AI assistant, empowered with Wild Moose's tools. Test-driven and feedback-powered. Agents are stress-tested against historical incidents and continuously refined based on your team's input. ## Get started Get Wild Moose connected and start building agents in minutes. Your AI guide for creating, testing, and refining debugging agents. Explore debugging agents, alert enrichment, and root cause analysis. Trigger investigations programmatically via the REST API. ## How it works A monitoring tool (Datadog, PagerDuty, etc.) posts an alert to one of your channels. An orchestrator dynamically selects and coordinates the right debugging agents based on the alert context. Multiple specialized agents query your observability stack - metrics, logs, traces, code changes - gathering evidence simultaneously. Each agent combines deterministic data collection with AI-powered synthesis to complete in seconds. Wild Moose posts a summary with root cause analysis, key findings, and actionable mitigations directly in the alert thread. # Microsoft Teams Source: https://docs.wildmoose.ai/integrations/microsoft-teams Use Wild Moose with Microsoft Teams Wild Moose works with Microsoft Teams, bringing AI-powered incident investigation directly into your team's workflow. It monitors alert channels, runs investigations, and posts enrichment results - just like it does in Slack. ## What Wild Moose does in Teams * **Monitors alert channels** - watches for incoming alerts from your monitoring tools. * **Posts enrichment threads** - investigation results appear as replies on the original alert message. * **Accepts keyword commands** - your team can interact with Wild Moose using specific keywords in Teams messages. * **Surfaces mitigations** - actionable remediation steps are posted alongside findings. ## Setup [Contact us](mailto:support@wildmoose.ai) to receive the Wild Moose Teams app package (a `.zip` file). A Teams admin uploads the app package via the Teams Admin Center. See Microsoft's guide on [uploading custom apps](https://learn.microsoft.com/en-us/microsoftteams/platform/concepts/build-and-test/apps-package) for details. Choose which Teams channels Wild Moose should monitor for incoming alerts. Set up debugging agents to define what Wild Moose investigates when alerts arrive. See [Debugging agents](/features/agents) for details. The investigation experience in Teams mirrors the Slack experience - same agents, same actions, same enrichment output. # Integrations overview Source: https://docs.wildmoose.ai/integrations/overview Connect Wild Moose to the tools your team already uses Wild Moose integrates with your existing observability, incident management, and development tools. All integrations are opt-in - connect as few or as many as you need. Once connected, Wild Moose can query these tools automatically during investigations. ## Alerting

**PagerDuty**

**OpsGenie**

**incident.io**

**FireHydrant**

**Rootly**

**Squadcast**

**BigPanda**

**Zenduty**

## Communication

**Slack**

**Microsoft Teams**

## Deployment

**GitHub Actions**

**Jenkins**

**Bitbucket**

**ArgoCD**

**Bash**

## Monitoring / Observability

**Datadog**

**Grafana**

**Loki**

**Mimir**

**Tempo**

**Prometheus**

**Elasticsearch**

**OpenSearch**

**Splunk**

**New Relic**

**Sentry**

**Sumo Logic**

**Coralogix**

**VictoriaMetrics**

**VictoriaLogs**

**Zabbix**

**Rollbar**

**PostHog**

**Mixpanel**

**Segment**

**SigNoz**

**Dynatrace**

**AppDynamics**

## Data Platforms / Query Engines

**PostgreSQL**

**MongoDB**

**BigQuery**

**Snowflake**

**ClickHouse**

**Supabase**

**SQL Databases**

**Trino**

## Ticketing / Project Management

**Jira**

**Confluence**

**Asana**

**Linear**

**Notion**

**Zendesk**

**Fibery**

## Extensibility

**MCP Servers**

**Internal Tools**

## Connecting a platform Our team helps you connect your tools during onboarding. Each integration uses read-only access with the minimum permissions required. Wild Moose uses read-only access to your observability tools. It queries data during investigations but never modifies your dashboards, alerts, or configurations. Don't see a tool you use? [Contact us](mailto:support@wildmoose.ai) - we're always adding new integrations. # Slack Source: https://docs.wildmoose.ai/integrations/slack Use Wild Moose with Slack Wild Moose integrates with Slack to bring investigations directly into your team's workflow. It monitors your channels, runs investigations, and posts enrichment results - all as threaded replies so your team stays in context. ## What Wild Moose does in Slack * **Monitors alert channels** - watches for incoming alerts from your monitoring tools. * **Posts enrichment threads** - investigation results appear as threaded replies on the original alert message. * **Accepts slash commands** - your team can trigger investigations and interact with Wild Moose directly via Slack slash commands. * **Surfaces mitigations** - actionable remediation steps are posted alongside findings. ## Setup Our team handles the Slack setup during onboarding. Here's what the process involves: Wild Moose is installed from the [Slack App Directory](https://slack.com/apps). Our team walks you through authorization and workspace configuration. Choose which Slack channels Wild Moose should monitor. These are typically channels where your monitoring tools (Datadog, PagerDuty, etc.) post alerts. Wild Moose needs permission to read messages in monitored channels and post threaded replies. The bot must be invited to each channel it should monitor. # Quick start Source: https://docs.wildmoose.ai/quickstart Get Wild Moose up and running ## Getting started Wild Moose works with your team during onboarding to get everything connected. Once your tools are linked, the [Moose Builder](/features/builder) guides you through creating your first debugging agents - no need to learn the system first. Wild Moose integrates with [Slack](/integrations/slack) and [Microsoft Teams](/integrations/microsoft-teams). Our team will help you get the app installed and connected to your alert channels. Connect the tools your team uses - Datadog, PagerDuty, Prometheus, or any of our [supported integrations](/integrations/overview). Each integration uses read-only access. Tell the [Moose Builder](/features/builder) what you want to investigate. It will create debugging agents, test them against your historical incidents, and refine them until they're finding root causes reliably. When an alert fires, Wild Moose automatically picks it up and runs the matching investigation. Results appear as a threaded reply in your alert channel - in seconds. Ready to get started? [Contact us](mailto:support@wildmoose.ai) and we'll help you get set up. ## What's next? Your AI guide for creating and testing debugging agents. Understand automatic vs. manual enrichment. # Security & Privacy Source: https://docs.wildmoose.ai/security How Wild Moose handles your data securely ## Data handling Wild Moose does not fine-tune or train AI models on your data. Instead, we analyze patterns across your systems to generate human-readable investigation plans that help resolve incidents faster. Wild Moose does not store logs, metrics, or other raw data. All processing happens in-memory and is ephemeral. The only retained output is structured metadata in the form of investigation plans, which can be reviewed to ensure no sensitive content is included. All integrations operate strictly in read-only mode. Wild Moose queries your observability tools during investigations but never modifies your dashboards, alerts, or infrastructure configurations. Each integration uses the minimum permissions required. For example, Slack access is limited to channels you explicitly configure - Wild Moose does not read messages in other channels. ## Data usage Wild Moose uses AI to analyze and correlate data across your environment for two primary purposes: * **Infer investigation flow** - based on investigation conversations, observability audit trails, and documentation, Wild Moose identifies typical troubleshooting patterns and workflows. * **Find root causes in real time** - using logs and metrics, Wild Moose detects patterns and relationships to expedite issue resolution. ## Compliance & encryption *

**SOC 2 Type 2 compliant** - Wild Moose adheres to SOC 2 Type 2 standards for data security, availability, and confidentiality. * **End-to-end encryption** - all communications and data exchanges are encrypted to ensure full confidentiality. * **Secure credential storage** - API tokens and integration credentials are stored in a secrets manager and encrypted at rest. ## Access requirements To enable Wild Moose for your environment, we require read-only access to the following: | Category | What's needed | | --------------------------------------- | ---------------------------------------------------------------------------------------------------------------- | | **Logs & metrics** | A read-only service account and API credentials for your observability platform (Datadog, Grafana, Splunk, etc.) | | **Runbooks & documentation** (optional) | Either read-only API access to relevant sources, or a one-time export of relevant information | | **Code & deployments** (optional) | Code repositories or deployment tools can be configured based on your stack | All integrations are opt-in. You can connect as few or as many data sources as you're comfortable with - Wild Moose works with whatever you provide. Have security questions? Contact us at [security@wildmoose.ai](mailto:security@wildmoose.ai).