# Anomaly Detection for Data Pipelines
Source: https://docs.corelayer.com/anomalies/overview
Corelayer detects silent data failures in pipelines and infrastructure, learning a statistical baseline per partition and flagging observations that fall outside it.
## What is Anomaly Detection?
Corelayer runs **anomaly rules** against your data. Each rule produces a stream of numeric observations, learns a statistical baseline for every partition in that stream, and raises a finding when a new observation falls outside the expected band.
There are two ways to feed observations into a rule:
* **Table rules** — Connect a database integration and attach a rule to a table. You describe what to watch in plain English, Corelayer compiles it to a read-only SQL query, and runs that query on a schedule.
* **API metrics** — Instrument your own code with the Corelayer SDK and push observations from any pipeline, ETL job, or service.
Both paths share the same baseline engine, the same detectors, and the same findings UI.
## How It Works
### 1. Create a rule
Go to **Anomaly Rules** in the sidebar and click **Add**. Pick a database table or a codebase, then configure the rule. See [Table Monitoring](/anomalies/table-monitoring) and [API Metrics](/anomalies/sdk-metrics) for the specifics of each.
### 2. Set the cadence and detector
Every rule has an **expected cadence** — hourly, daily, weekly, or monthly — which sets how observations are bucketed and, for table rules, how often the query runs.
Every rule also has a **detector**: the statistical method that scores each observation. For API metrics you choose it yourself, and `Baseline` is the default. For table rules Corelayer derives it from **Analyze Setup**.
### 3. Build the baseline
A rule needs history before it can judge anything. Until a partition has enough observations, it shows as **Collecting** and reports nothing.
* **Table rules** can train instantly using **Save & Backfill**, which runs the rule over historical rows.
* **API metrics** collect forward from the first observation your SDK sends.
Once a partition has enough data points, it flips to **Ready**.
### 4. Detection
On each run, Corelayer compares the new observation against that partition's expected band. Anything outside the band is recorded as a **finding**, with a severity scaled to how far past the boundary it landed.
### 5. Review and triage
Findings appear on the rule's detail page with a severity (**Critical**, **High**, **Medium**, **Low**, **Info**), the observed value, the expected value, and the band that was breached.
Findings are also escalated for automated triage, which can open a Corelayer issue — the finding then links to that issue and shows whether it is still open. Breaches that only marginally clear the boundary are recorded but not escalated, so near-misses do not generate issues.
## Detectors
Pick the detector that matches the shape of your metric.
| Detector | Use it for |
| -------------- | ------------------------------------------------------------------------------------------------------ |
| **Baseline** | The default. A robust band around the mean, at `k` standard deviations. Good for most metrics. |
| **Asymmetric** | Skewed or one-sided metrics, where a spike up matters but a dip down does not (or vice versa). |
| **Seasonal** | Metrics with a repeating daily or weekly cycle. |
| **Count** | Low-rate integer counts, where normal values are small and a Gaussian band would be wrong. |
| **Conformal** | Distribution-free scoring, when the metric does not look normal and you do not want to assume a shape. |
| **CUSUM** | Sustained level shifts, where the metric moves to a new plateau rather than spiking. |
Each detector keeps its own rolling window, so switching detectors on an existing rule retrains it from stored history.
## Key Concepts
* **Observation** — One numeric value for one partition at one point in time. A rule run produces a batch of them.
* **Partition** — A logical slice of the stream, identified by its partition keys. Every partition gets its own independent baseline. Partitioning by `region` and `pipeline` gives you a separate baseline for each region-pipeline pair.
* **Baseline** — The statistical state learned from a partition's recent observations, used to compute the expected band.
* **Detector** — The method that turns a baseline plus a new observation into a pass or a finding.
* **Minimum data points** — How many observations a partition must accumulate before the detector is allowed to flag anything. Leave it blank to use the detector's default. Lower values alert sooner but are noisier.
* **Cadence** — How often observations are expected to arrive: hourly, daily, weekly, or monthly. It sets how observations are bucketed and, for table rules, how often the query runs.
* **Finding** — A recorded anomaly, with severity, observed value, expected value, and the breached bounds.
## Getting Started
Describe an anomaly in plain English and monitor a database table.
Push custom metrics from your own pipelines using the Corelayer SDK.
Need help? [Contact support](mailto:support@corelayer.com) for assistance with anomaly detection.
# API Metrics: Track Custom Pipeline Metrics
Source: https://docs.corelayer.com/anomalies/sdk-metrics
Instrument any pipeline or application with the Corelayer SDK to push custom metrics, build baselines per partition, and detect anomalies in your own data.
## Overview
API metrics let you track custom data quality metrics from any codebase — ETL pipelines, batch jobs, microservices, or applications. You push observations with the Corelayer SDK; Corelayer builds a statistical baseline for each partition and raises findings when values fall outside the expected band.
## Prerequisites
* A connected GitHub or GitLab integration, with the repository you want to track synced to Corelayer
* Node.js 18 or later (the SDK uses the built-in `fetch`)
## Onboarding
### 1. Create an API key
1. In your Corelayer dashboard, go to **Settings > API Keys**
2. Click **Create Key**
3. Give it a name (for example `Production ETL`) and choose an expiration — never, 30, 60, or 90 days, or 1 year
4. Click **Create**
5. Copy the key immediately. It starts with `cl_live_` and is shown only once.
### 2. Set the environment variables
```bash theme={null}
export CORELAYER_API_KEY="cl_live_your_api_key_here"
export CORELAYER_BASE_URL="https://api.corelayer.com"
```
For production, set both in your environment configuration — `.env`, Docker secrets, CI/CD variables, or your cloud provider's secret manager.
### 3. Install the SDK
```bash theme={null}
npm install @corelayer-ai/sdk
```
### 4. Create the rule in the dashboard
1. Go to **Anomaly Rules** and click **Add**
2. Under **Codebases**, pick the repository
3. Click **Add API metric**
4. Fill in the configuration:
* **Anomaly rule name** — a human-readable label, for example `Daily Order Volume`
* **Expected cadence** — how often your application sends this metric (hourly, daily, weekly, monthly)
* **Detector** — which statistical method scores the metric. `Baseline` is the default; see [Detectors](/anomalies/overview#detectors).
* **Minimum data points** — how many observations to learn before flagging. Leave blank for the detector default.
5. Copy the **Metric ID** and the **SDK snippet** from the page
6. Click **Save**
The page also offers a **Copy agent instructions** button, which puts a short Markdown brief on your clipboard — paste it into a coding agent to have it wire up the SDK for you.
### 5. Instrument your code
```javascript theme={null}
import { CorelayerClient } from '@corelayer-ai/sdk';
const client = new CorelayerClient({
apiKey: process.env.CORELAYER_API_KEY,
baseUrl: process.env.CORELAYER_BASE_URL,
});
client.trackMetric({
metricId: "",
partitions: [
{ keys: { "region": "us-east-1", "table": "orders" }, value: 1523 },
],
timestamp: "2025-01-15T00:00:00Z",
});
// Call at process exit to flush remaining metrics
await client.shutdown();
```
**Parameters**:
* `metricId` — the UUID from step 4. Identifies which rule this data belongs to.
* `partitions` — an array of partition entries. Each has `keys` (an object of key/value pairs identifying the partition) and `value` (the numeric measurement). Each unique key combination gets its own baseline.
* `timestamp` — an ISO 8601 timestamp. Optional; defaults to now. Pass it explicitly for batch jobs so reruns bucket correctly.
Always set `CORELAYER_BASE_URL`. If you omit `baseUrl`, the SDK falls back to a built-in default that is not the production API.
### 6. Deploy and monitor
Once your code is deployed and sending data, Corelayer will:
1. Collect observations to build a baseline for each partition — the rule shows **Collecting**
2. Switch to active monitoring once a partition has enough data — it shows **Ready**
3. Flag observations that fall outside the expected band
## Client Configuration
`trackMetric` queues locally and flushes in the background, so it does not block your pipeline.
| Option | Default | Description |
| ----------------- | ------- | ------------------------------------------------------------------------------------------------ |
| `apiKey` | — | Required. Your `cl_live_` API key. |
| `baseUrl` | — | Set to `https://api.corelayer.com`. |
| `flushIntervalMs` | `5000` | How often the queue is flushed. |
| `maxBatchSize` | `100` | Batch size. Reaching it triggers an immediate flush. |
| `maxQueueSize` | `1000` | Queue cap before entries are dropped. |
| `maxRetries` | `4` | Retries per batch on `429` and `5xx`, with backoff of 500ms, 1s, 2s, 4s, honoring `Retry-After`. |
| `timeoutMs` | `5000` | Per-request timeout. |
| `debug` | `false` | Log delivery failures to the console. |
`flush()` and `shutdown()` do not throw on delivery failure. Set `debug: true` while integrating so failed batches are visible.
## Environment Variables Reference
| Variable | Required | Description |
| -------------------- | -------- | ---------------------------------------------------------------------------- |
| `CORELAYER_API_KEY` | Yes | API key for authenticating SDK calls. Create one at **Settings > API Keys**. |
| `CORELAYER_BASE_URL` | Yes | The Corelayer API endpoint. Set to `https://api.corelayer.com`. |
## Viewing Metrics
### Rule listing
From **Anomaly Rules**, the **API** section groups codebases by account and shows how many rules each has. Open a codebase to see its rules. Each row shows the rule name, its cadence, and whether the baseline is **Collecting** or **Ready**.
### Rule detail page
Open a rule to see the **Overview** tab:
* **Stat cards** — partitions observed, baselines ready, and anomalies detected in the selected range
* **Time range selector** — presets scaled to the rule's cadence (an hourly rule offers 1d/3d/7d, a daily rule 7d/14d/30d, a weekly rule 90d/6mo/1y, a monthly rule 6mo/1y/2y)
* **Partition Inspector** — a searchable, paginated list of partitions showing mean, min, and max with a sparkline. Select one to load its chart, baseline state, and findings.
* **Anomaly findings** — findings for the selected partition
Click **Configure** to open the **Settings** tab and edit the rule.
### Anomaly findings
Each finding shows:
* **Severity** — Critical, High, Medium, Low, or Info
* **Detector** — which method produced it
* **Observed vs. Expected** — the actual value against what the baseline predicted
* **Expected range** — the bounds that were breached
* **Timestamp** — when it was detected
* **Linked issue** — if the finding opened a Corelayer issue, a link to it and whether it is still open
## Tips
* **Use descriptive partition keys** — keys like `region`, `pipeline`, or `table_name` make findings easier to diagnose.
* **Set explicit timestamps for batch jobs** — this keeps data bucketed correctly, even during reruns.
* **Call `client.shutdown()`** — always flush before your process exits, or the last batch is lost.
* **One rule per logical measurement** — keep `Order Volume` and `Payment Processing Time` as separate rules rather than mixing them.
* **Do not over-partition** — every unique key combination needs enough observations of its own to train. Too many partitions means none of them reach **Ready**.
## Managing Rules
### Changing the detector or cadence
Open the rule and switch to **Settings**. Changing the **detector** retrains from stored history automatically. Changing the **expected cadence** re-buckets observations, so Corelayer asks whether to keep the existing baseline or reset it — keeping it can produce noisy findings until enough new observations arrive.
**Reset Baseline** discards learned state and rebuilds from scratch on the next run.
### Deleting rules
On a codebase's rule list, select one or more rules with the checkboxes and click **Delete**. This permanently removes the rules and their history.
### Rotating API keys
1. Go to **Settings > API Keys**
2. Click the rotate icon next to the key
3. Copy the new key and update `CORELAYER_API_KEY`
4. The old key is revoked immediately
Need help? [Contact support](mailto:support@corelayer.com) for assistance with API metrics.
# Database Table Monitoring and Alerts
Source: https://docs.corelayer.com/anomalies/table-monitoring
Describe an anomaly in plain English, let Corelayer compile it to read-only SQL, and monitor any table in a connected database on a schedule.
## Prerequisites
* A connected database integration (for example AWS RDS, ClickHouse, or PlanetScale)
* At least one table synced from that database
## Setting Up a Table Rule
### 1. Open Anomaly Rules
In your Corelayer dashboard, go to **Anomaly Rules** in the sidebar.
### 2. Add a rule
Click **Add**. The picker lists your resources under **Tables** and **Codebases**, with tables grouped by provider, account, database, and schema. Use the search box to filter by table, database, or schema name.
Select a table to open its rule list, then click **Add** again to create a new rule against it. A table can carry more than one rule, so you can monitor row volume, a revenue column, and a null rate as three independent rules.
### 3. Describe the anomaly
On the left of the editor, describe in plain English what you want to catch, for example:
```
Alert me when the daily count of orders per region drops well below normal
```
The panel shows the table's columns for reference. For `jsonb` columns you can expand the column to inspect the keys inside it.
Click **Generate SQL**. Corelayer compiles your description into a read-only query and fills in the **Compiled Anomaly** panel on the right, along with a confidence score.
### 4. Review and edit the SQL
The generated SQL is fully editable — treat the generation step as a starting point, not a black box.
Your query must return an **`observed_value`** column: the number being monitored. It can also return any of these optional columns to control partitioning and time handling:
| Column | Purpose |
| ---------------------------------- | -------------------------------------------- |
| `entity_key` | Partition identity as a key/value structure |
| `partition_key` | Partition identity as a single value |
| `partition_start`, `partition_end` | Bounds of the partition the value belongs to |
| `window_start`, `window_end` | Bounds of the window the query scanned |
| `observed_at` | Timestamp for the observation |
Queries must be read-only. Corelayer rejects anything that is not a `SELECT` or `WITH`, and blocks table and file functions that could read files or reach the network (`url`, `s3`, `remote`, `file`, `dblink*`, `http*`, `pg_read_file`, and similar). The guard is enforced both when you save and again at execution time.
Give the rule a name in **Anomaly Name**.
### 5. Validate and analyze
* **Validate** runs the query against your database and shows the returned columns, a bounded sample of rows, and whether the output contract is satisfied.
* **Analyze Setup** goes further: it estimates how much history is available, whether partitions will reach a trained baseline, and which detector suits the data. Blocking errors and warnings are listed underneath.
Unlike API metrics, table rules do not ask you to pick a detector — Corelayer derives it from the setup analysis. Editing the SQL, the cadence, or the schedule clears the analysis, so re-run **Analyze Setup** before saving.
### 6. Set the schedule
The schedule controls sit above the description panel and set how often the rule runs:
* **Cadence** — every hour, every day, every week, or on the 2nd of every month
* **Day of week** — for weekly rules
* **Time of day** and **time zone** — when the run fires
### 7. Save
Click **Save & Backfill** to save the rule and immediately train the baseline from historical rows — this is the default and gets you to a working rule fastest. Use the dropdown next to the button to choose **Save without backfill** if you would rather collect forward from now.
## Understanding the Dashboard
### Anomaly Rules list
The **Anomaly Rules** page lists your rules in two sections:
* **Table** — rules attached to database tables, grouped by connection
* **API** — codebases reporting SDK metrics, with a count of rules each
Each row shows the rule name, its cadence, and whether its baseline is **Collecting** or **Ready**.
### Rule detail page
Opening a rule shows the **Overview** tab:
* **Stat cards** — partitions observed, baselines ready, and anomalies detected in the selected range
* **Time range selector** — preset windows scaled to the rule's cadence (an hourly rule offers 1d/3d/7d, a daily rule 7d/14d/30d, a weekly rule 90d/6mo/1y, a monthly rule 6mo/1y/2y)
* **Partition Inspector** — a searchable, paginated list of partitions showing mean, min, and max with a sparkline. Select one to load its chart, baseline, and findings.
* **Anomaly findings** — the findings for the selected partition, each with severity, detector, observed value, expected value, expected range, and a link to the issue it opened
Click **Configure** to switch to the **Settings** tab and edit the rule.
## Baselines
A rule reports nothing until a partition's baseline is trained.
* **Save & Backfill** trains from historical rows in one pass. The panel reports **Backfill running**, then **Baseline trained** with the number of baseline entries, or **Backfill failed** with the error.
* Without a backfill, each partition shows **Baseline warming · N/M observations** until it reaches the minimum.
**Reset Baseline** discards learned state; the next scheduled run rebuilds it from scratch. Changing the detector retrains automatically from stored history.
## Managing Rules
### Editing
Open a rule, switch to the **Settings** tab, change what you need, and click **Save**. **Discard** reverts unsaved edits.
### Deleting
Use **Delete** on the rule's detail page, or select rules with the checkboxes on a table's rule list and click **Delete**. This permanently removes the rules and their history.
## Troubleshooting
### Baseline not ready?
* Run **Analyze Setup** — it reports directly whether there is enough history to train
* Re-save with **Save & Backfill** to train from history instead of waiting
* Check that the table is still receiving rows at the configured cadence
* Confirm your partitioning is not splitting the data so finely that no partition accumulates enough observations
* Verify the database integration is still connected and healthy
### No anomalies detected?
* Confirm the partition shows **Ready**, not **Collecting**
* Widen the time range selector
* Check the last run succeeded — a failed run reports under the baseline status
* Findings that only marginally clear the band are suppressed as noise by design
### Generated SQL is wrong?
Edit it directly, then **Validate** to check the output contract and see sample rows. Rewriting the description and regenerating is often faster than hand-editing a complex query.
Need help? [Contact support](mailto:support@corelayer.com) for assistance with table monitoring.
# Corelayer Changelog: April 2026 Release
Source: https://docs.corelayer.com/changelog/april-2026
April 2026 Corelayer release notes: MCP server, bulk close, non-interactive CLI auth, agent-agnostic skill, PII masking, anomaly detection, 15 integrations.
## MCP server
You can now connect AI agents and MCP-compatible tools to Corelayer using the Model Context Protocol. Agents can list groups, browse issues, read root-cause analyses, check integrations, and search organization memory — all through standard MCP tooling.
Two connection modes are available:
* **Remote MCP** — Point any hosted connector at `https://api.corelayer.com/mcp` with a bearer token. No install required.
* **Local MCP** — Run `npx -y @corelayer-ai/mcp` as a stdio server for coding agents that use local MCP.
[Set up the MCP server](/cli/mcp-server)
## Bulk close
A new `bulk-close` command lets you close a large set of stale issues in one operation instead of closing them one at a time. Filter by last-seen date and attach feedback in a single call.
```bash theme={null}
corelayer issues bulk-close --group --last-seen-before-or-on 14days --feedback "stale, closing"
```
This is especially useful for agents and scripts managing issue backlogs at scale.
[View CLI docs](/cli/overview)
## Non-interactive CLI authentication
The CLI now supports API key authentication via the `CORELAYER_API_KEY` environment variable, so you can use Corelayer in CI/CD pipelines, background agents, and headless environments without a browser login.
You can also pipe an existing token into the CLI config:
```bash theme={null}
printf '%s' "$CORELAYER_API_KEY" | corelayer login --with-token --api-url https://api.corelayer.com
```
[Read more about CLI auth](/cli/overview)
## Agent skill is now agent-agnostic
The CLI's built-in skill — previously called the "Claude Code skill" — has been generalized to work with any supported AI agent runtime. Run `corelayer install-skill` to install it, regardless of which coding agent you use.
[Set up the Corelayer skill](/cli/corelayer-skill)
## Corelayer CLI
You can now manage Corelayer from the terminal. The CLI lets you list groups, view and triage issues, check integrations, and get issue summaries — all without leaving your editor.
Install it with `npm install -g @corelayer-ai/cli` and sign in with `corelayer login`, which authenticates through your browser in one step.
The CLI also supports a machine-readable `--json` mode, making it easy to integrate with scripts and AI agents.
[Read the CLI docs](/cli/overview)
## Claude Code skill for the CLI
The Corelayer CLI now ships with a built-in Claude Code skill. Run `corelayer install-skill` and Claude Code will automatically know how to use the Corelayer CLI whenever you mention production issues, monitoring, or triage.
This is especially useful for background agents that need to query Corelayer without manual prompting.
[Set up the skill](/cli/corelayer-skill)
## PII masking
Corelayer now redacts sensitive data — like email addresses, API keys, credit card numbers, and more — before it appears in issue summaries, notifications, or AI investigation output.
Masking is on by default for secrets, personal info, and financial data. You can toggle additional categories like network addresses and identifiers in **Settings → Privacy**.
[Learn about PII masking](/security/pii-masking)
## Anomaly detection
You can now monitor your data for unexpected changes using two approaches:
* **Table monitoring** — Connect a database and track row volume, column values, and schema changes automatically.
* **SDK metrics** — Instrument your code with the Corelayer SDK to track custom metrics from any pipeline or application.
Corelayer builds statistical baselines and alerts you when values fall outside expected ranges.
[Get started with anomaly detection](/anomalies/overview)
## 15 integrations
Corelayer now connects to your full stack. New integrations include:
* **Cloud**: AWS, GCP, Cloudflare, Oracle Cloud
* **Observability**: Datadog, Sentry
* **Code**: GitHub
* **Notifications**: Slack, Microsoft Teams
* **Databases**: ClickHouse, PlanetScale
* **Platforms**: Airflow, Trigger.dev, Vercel, incident.io, Merge
[Browse all integrations](/integrations/aws)
# August 2026
Source: https://docs.corelayer.com/changelog/august-2026
Worked Honeycomb Triggers and Grafana webhook payload templates for the Custom Webhook, mapping native fields to Corelayer's canonical alert schema.
## Custom Webhook: Honeycomb and Grafana payload templates
The Custom Webhook setup now includes worked payload templates for Honeycomb Triggers and Grafana webhook contact points. Each provider section maps the tool's native fields to the canonical alert schema, including `action` transitions between `trigger` and `resolve`, RFC 3339 timestamp formatting, and stable `fingerprint` grouping across repeated firings.
[Map a provider's native payload](/integrations/custom-webhook#mapping-a-providers-native-payload)
# Corelayer Changelog: December 2025, v1.0.0
Source: https://docs.corelayer.com/changelog/december-2025
December 2025 Corelayer release notes for v1.0.0, the general availability launch of the Corelayer AI SRE and production support platform for teams.
## v1.0.0 — Corelayer General Availability
Corelayer has reached general availability. The platform combines incident detection, AI-assisted investigation, and collaboration workflows into a single product for production teams.
### Key features
* **Unified issue workflow** for triage, root-cause tracking, and follow-up actions
* **AI-generated investigations** covering what happened, root cause, and next steps
* **Integrations framework** for ingesting operational signals from external systems
* **Severity-aware issue management** with open/close lifecycle workflows
* **Team-oriented UX** for reviewing incidents and coordinating action
### Migration notes
No migration is required for current users. This marks the first stable, production-ready version intended for broad customer use; the core product surface is now complete and will evolve through subsequent minor releases.
# Corelayer Changelog: February 2026, v1.2.0
Source: https://docs.corelayer.com/changelog/february-2026
February 2026 Corelayer release notes for v1.2.0: Deep Research for longer autonomous investigations and the Anomaly Detection SDK for custom pipeline metrics.
## v1.2.0 — Deep Research & Anomaly Detection SDK
This release shifts Corelayer from monitoring into guided investigation and programmable anomaly detection.
### Key features
* **Deep Research** — analyze incidents across logs, alerts, and contextual data
* **Structured research outputs** covering incident descriptions, probable root causes, and recommended actions
* **Anomaly Detection SDK (v1)** — ingest custom operational signals into detection systems
* **Severity-aware routing** for faster triaging of high-signal anomalies
* **Strengthened collaboration workflows** connecting detection, investigation, and issue tracking
Teams can now move from detection to explanation faster, while extending Corelayer with domain-specific anomaly signals through the SDK.
# Corelayer Changelog: January 2026, v1.1.0
Source: https://docs.corelayer.com/changelog/january-2026
January 2026 Corelayer release notes for v1.1.0: dynamic dependency maps for tracing across services and reliability improvements across every integration.
## v1.1.0 — Dynamic Maps & Integration Reliability
Corelayer eliminated static map definitions in favor of live topology mapping, and strengthened integration reliability across sync and digest workflows.
### Key changes
* Transitioned from hardcoded map definitions to **dynamic topology generation**
* Dependency and ownership relationships now refresh automatically as infrastructure evolves
* **Enhanced sync reliability** for external integrations with improved failure handling
* **Reinforced digest scheduling** to prevent incomplete states during downstream failures
* Improved operator experience through clearer error messaging and faster credential issue detection
Service maps stay accurate as systems change, and integration problems surface and are handled more reliably.
# Corelayer Changelog: June 2026 Release
Source: https://docs.corelayer.com/changelog/june-2026
June 2026 Corelayer release notes: preflight checks to catch issues before deploy, organization memory, CLI issue slug lookup, and post-deploy issue diffing.
## Scheduled tasks from Slack
You can now ask Corelayer in Slack to run a task on a schedule and post the result back to the same channel. Recurring checks, fixed intervals, and one-shot reminders are all supported — for example, "every weekday at 9am, post a summary of open critical issues" or "remind me in 20 minutes to check this issue again."
Scheduled runs are read-only: they can investigate, summarize, and report back, but they cannot change settings or create more scheduled tasks. If you use a local time, include the timezone so it's scheduled correctly.
[Set up scheduled tasks in Slack](/integrations/slack#scheduled-tasks-from-slack)
## Service Map removed
Service Map has been retired and is no longer available across integrations. Existing investigations and integrations are unaffected — Corelayer continues to correlate signals from connected sources without it.
[Browse integrations](/integrations/aws)
## Preflight checks before you ship
Check a change against your organization's memory before opening a pull request. Preflight takes the PR's description and returns the failure modes, facts, and preferences the org has hit before for a change like that — grounded reminders to double-check, or nothing when memory has no relevant lesson.
```bash theme={null}
corelayer preflight
```
Run inside a repository and it derives the change from the current branch. It's also available to agents as the `corelayer.preflight` MCP tool and through the Corelayer skill, so an assistant can run it when you're about to open a PR.
[Learn about preflight](/memory/overview#preflight-checking-a-change-before-you-ship)
## Organization memory
A per-organization memory that records your feedback and what Corelayer learns from incidents, and applies it automatically.
* Closing an issue as a false positive, by design, or "don't alert" records a preference — matching signals are suppressed instead of re-alerting. Feedback like "fixed" or "duplicate" is not suppressed, so regressions still surface. Reopening an issue reverses what closing it taught.
* Teaching the assistant a preference, fact, or decision in chat saves it to memory.
* Learned failure patterns from past incidents feed every new investigation, ranked by relevance, confidence, and recency.
Cortex, in the sidebar, shows what Corelayer has learned about each system — read, edit, archive, or restore any memory.
[Learn about organization memory](/memory/overview)
## CLI issue slug lookup and diffing
The Corelayer CLI now supports issue lookup by either UUID or issue slug:
```bash theme={null}
corelayer issues get --json
```
You can also diff issues changed after a deploy, merge, timestamp, or recent time window:
```bash theme={null}
corelayer issues diff --group --since 2026-06-04T20:00:00Z --json
corelayer issues diff --group --duration 2hours --limit 50 --json
```
Diff responses are paginated and include `since`, `issues`, `total`, `page`, and `limit`, making them easier to use in scripts and background triage agents.
[Use the Corelayer CLI](/cli/overview)
# Corelayer Changelog: March 2026, v1.3.0
Source: https://docs.corelayer.com/changelog/march-2026
March 2026 Corelayer release notes for v1.3.0: the REST API, the first Corelayer CLI, and agent learnings that carry incident context between investigations.
## v1.3.0 — REST API, CLI & Agent Learnings
This release introduces the V1 REST API with API key authentication and RBAC, a full CLI for managing issues and integrations from the terminal, operational learnings extraction from agent tool traces, and reliability fixes for SQS retry handling.
### V1 REST API
Corelayer now exposes a full REST API (`api/v1`) for programmatic access to issues, groups, integrations, events, anomaly configs, deep research, and settings. The API uses **API key authentication** with **role-based access control (RBAC)** and includes per-key rate limiting with configurable tiers.
### Corelayer CLI
A new CLI package (`@corelayer-ai/cli`) lets you manage issues, view groups, configure integrations, and authenticate — all from your terminal. Built with production hardening including request timeouts, file permission validation, and secure credential storage.
[Read the CLI docs](/cli/overview)
### Agent Learnings
The investigation agent now extracts operational learnings from tool execution traces after each analysis. Learnings are deduplicated, merged with existing knowledge, and stored with full provenance tracking so the agent builds institutional memory over time.
### Reliability improvements
Fixed a bug where interrupted analyses would never complete on SQS retry. Added completeness guards, orphaned event cleanup, and corrected retry-path event routing to prevent duplicate issue creation.
### Other changes
* Removed legacy internal HMAC authentication in favor of API key auth
* Fixed rate limit Postgres upsert typing
* Added bulk-action validation to prevent silent issue reopening
* Improved fingerprint-based issue grouping
# Corelayer Changelog: May 2026 Release
Source: https://docs.corelayer.com/changelog/may-2026
May 2026 Corelayer release notes: the Custom Webhook integration, which accepts alerts from any monitoring tool through a single generic endpoint.
## Custom Webhook integration
You can now send alerts to Corelayer from any monitoring or alerting tool using a generic webhook endpoint. This unlocks sources that don't have a first-party integration yet — including Grafana, Alertmanager, and in-house monitors.
Each webhook source gets a unique URL and bearer token, with a ready-to-copy `curl` command for verification. `trigger` alerts start a Corelayer investigation automatically, with fingerprint-based deduplication for repeated alerts.
You can create multiple webhook sources from the same integration, reset tokens, and enable or disable individual sources without losing their configuration.
[Set up custom alerts](/webhooks/custom)
# September 2026
Source: https://docs.corelayer.com/changelog/september-2026
September 2026 Corelayer release notes: environment-aware analysis with Slack routing, typed Webhook providers, and incident.io declared incidents.
## Environment-aware analysis and Slack routing
Corelayer now infers the environment associated with an issue from the available context and considers it during investigation and impact assessment. Environments such as production, staging, and development are distinguished automatically.
Slack notifications can be routed by environment and severity. Configure destination channels in your Slack integration settings and pick the environment and severity criteria for each route. For example, send critical production issues to your on-call channel and staging issues to a staging channel.
[Route notifications by environment and severity](/integrations/slack#route-notifications-by-environment-and-severity)
## Dedicated Webhooks with typed providers
Webhooks are now a first-class area in the sidebar with typed presets for each source. Choose a **Webhook type** when adding a webhook, and Corelayer supplies the URL, token, and provider-specific payload template.
Supported types:
* [incident.io](/webhooks/incidentio) — alerts and declared incidents using a signing secret
* [Honeycomb](/webhooks/honeycomb) — trigger alerts using a webhook recipient and shared secret
* [CloudWatch](/webhooks/cloudwatch) — alarm state changes through an EventBridge API destination
* [Datadog](/webhooks/datadog) — monitor notifications using a webhook payload template
* [Custom alerts](/webhooks/custom) — the generic JSON format with a bearer token
Each source can be enabled or disabled without losing its configuration, deleted from the list, and rotated for a new bearer token when needed.
[Browse webhook sources](/webhooks/overview)
## incident.io declared incidents
The incident.io webhook now investigates declared incidents in addition to alerts. Subscribe to `public_incident.incident_created_v2` or `private_incident.incident_created_v2` on your endpoint and Corelayer opens an investigation using the incident reference, name, and summary, with severity, status, incident type, mode, visibility, Slack channel, role assignments, and custom fields recorded as labels.
Alert resolution events (`alert_resolved_v1`) are now recorded against the originating alert. Corelayer reads from incident.io and does not write changes back.
Endpoints created before declared incident support are alert-only and are not updated automatically. Add the incident-created events to an existing endpoint to receive declared incidents.
[Configure the incident.io webhook](/webhooks/incidentio)
# Corelayer Skill for AI Coding Agents
Source: https://docs.corelayer.com/cli/corelayer-skill
Install the Corelayer skill so any supported AI coding agent knows how to use the CLI for production triage, monitoring, and incident tasks without prompting.
## Overview
The Corelayer CLI ships with a built-in **Corelayer skill**. Once installed, supported AI agents can automatically use the Corelayer CLI whenever you mention production issues, errors, monitoring, or triage without needing to re-read `--help` or be told how the CLI works.
This is useful for:
* Developers who use AI coding agents as their daily assistant
* Background agents that monitor or triage production issues on a schedule
* Anyone who wants an agent to reach for `corelayer` commands instead of raw HTTP requests
## Install the Skill
```bash theme={null}
corelayer install-skill
```
This installs the skill file for supported agent runtimes.
## Verify Installation
After installing, start a new agent session. The skill should appear anywhere your agent exposes installed skills or command packs.
If your agent supports manual invocation, use that tool's native mechanism to load the Corelayer skill.
## What the Skill Teaches the Agent
The skill gives the agent complete knowledge of the Corelayer CLI:
* All commands and their flags (`issues list`, `issues get`, `issues close`, `groups list`, etc.)
* Global flags (`--json`, `--quiet`, `--api-url`, `--no-color`)
* Common workflows (checking production health, triaging issues, diffing issues after deploys, scripting with JSON output)
* Background agent best practices (`--json` for structured output, `--quiet` to suppress interactive messages, `default-group` to avoid repeating group IDs)
## Auto-Trigger
On agents that support automatic skill loading, the skill can activate when you mention:
* Production issues, errors, or monitoring
* Incidents or root cause analysis
* Issue triage
* "Check prod", "what's broken", "any errors"
* Opening a pull request, or "check this PR against Corelayer" / "run a preflight check"
* Corelayer by name
You may not need to invoke the skill manually, depending on how your agent handles installed skills.
## Background Agent Setup
Background agents benefit the most from the skill because they cannot interactively read `--help`. To set up a background agent:
1. Install the CLI and authenticate:
```bash theme={null}
npm install -g @corelayer-ai/cli
corelayer login
```
2. Set a default group so the agent does not need to pass `--group` on every call:
```bash theme={null}
corelayer config set default-group
```
3. Install the skill:
```bash theme={null}
corelayer install-skill
```
The agent will now use `--json` for structured output and know the full command surface without additional prompting.
## Uninstall the Skill
```bash theme={null}
corelayer uninstall-skill
```
This removes the installed skill files.
## How It Works
The skill is a Markdown file (`SKILL.md`) containing:
* **Frontmatter** with trigger keywords that tell the agent when to load the skill
* **Instructions** with the full CLI command reference, flags, and workflows
The `install-skill` command copies this file from the CLI package into the local skill location used by supported agent runtimes. The underlying guidance is agent-agnostic even when a given installer targets a specific runtime's skill directory.
# Corelayer MCP Server for AI Agents
Source: https://docs.corelayer.com/cli/mcp-server
Connect AI agents to Corelayer over the Model Context Protocol to browse issues, read root-cause analyses, and search organization memory. Remote or local.
## Overview
The Corelayer MCP server lets AI agents access Corelayer through the Model
Context Protocol (MCP). Agents can discover Corelayer groups, list issues, read
issue details, inspect summaries, search organization memory, and use that
context in their normal workflows.
Use Corelayer MCP when you want an AI tool to answer questions like:
* "What are the highest-priority open production issues right now?"
* "Search our Corelayer memory for previous decisions about this incident."
* "Find issues in the workspace, then create tickets or daily summaries in my
planning tool."
Corelayer supports two MCP connection modes:
| Mode | Best for | Install required? |
| ---------- | ----------------------------------------------- | ----------------- |
| Remote MCP | Hosted connectors, team workflows, web agents | No |
| Local MCP | Coding agents that run local stdio MCP commands | Yes, via `npx` |
For most hosted connectors, use the remote MCP endpoint:
```text theme={null}
https://api.corelayer.com/mcp
```
## Remote MCP
Remote MCP is the easiest way to connect a hosted AI agent or connector to
Corelayer. The agent talks to Corelayer over HTTPS and authenticates with a
Corelayer API key.
Remote MCP requires an MCP host that supports HTTP MCP servers and bearer-token
authentication. If your host only supports local stdio MCP servers, use the
local package below.
Use this connection shape in MCP clients that support remote HTTP servers:
```json theme={null}
{
"mcpServers": {
"corelayer": {
"url": "https://api.corelayer.com/mcp",
"headers": {
"Authorization": "Bearer cl_key_..."
}
}
}
}
```
Some MCP hosts use `serverUrl` instead of `url`, or collect the bearer token in
a separate authentication field. Use your host's MCP configuration format, but
keep the same endpoint and authorization header.
Remote MCP currently exposes read-only tools. It does not expose close, reopen,
or bulk close operations.
## Authentication
Create a dedicated API key for your MCP connector:
```bash theme={null}
corelayer api-keys create --name "Corelayer MCP"
```
Use the returned key as the bearer token:
```text theme={null}
Authorization: Bearer cl_key_...
```
Use a dedicated key per connector or automation. This makes it easier to audit,
rotate, and revoke access without disrupting other workflows.
## How Connectors Find a Group
Most Corelayer tools are scoped to a group. A connector does not need to know
the `groupId` before setup.
The normal connector flow is:
1. Call `corelayer.list_groups`.
2. Let the agent pick the matching group by name, or ask the user to choose.
3. Pass the selected group's `id` as `groupId` to group-scoped tools.
For example, an agent instruction can say:
```text theme={null}
First call corelayer.list_groups to find the Corelayer group for this
workspace. Use the group whose name matches this team. If more than one group
looks relevant, ask me which one to use. Use that groupId for future Corelayer
calls.
```
This is the recommended pattern for hosted connectors because it avoids asking
users to copy internal IDs during setup.
## Available Remote Tools
| Tool | Type | Description |
| ----------------------------- | ---- | -------------------------------------------------------------------------------- |
| `corelayer.list_groups` | Read | List Corelayer groups the API key can access. |
| `corelayer.list_issues` | Read | List issues for a group with filters and pagination. |
| `corelayer.get_issue` | Read | Fetch detailed issue context, root cause, trace, and metadata. |
| `corelayer.get_issue_summary` | Read | Fetch issue summary statistics for a group. |
| `corelayer.list_integrations` | Read | List connected integration accounts for a group. |
| `corelayer.search_org_memory` | Read | Search organization memory for historical context. |
| `corelayer.preflight` | Read | Check a PR description against org memory; return failure modes to double-check. |
## Example Connector Workflows
Daily triage:
```text theme={null}
Use Corelayer to list open issues in our workspace. Summarize the top issues by
severity, last seen time, and event count. If any issue looks fixed based on
recent context, include it in a separate "needs human review" section.
```
Ticket creation:
```text theme={null}
Find high and critical Corelayer issues from the selected group. For each issue
that does not already have a ticket, draft a concise ticket with the issue
title, root cause, affected service, and recommended next step.
```
Historical context:
```text theme={null}
Search Corelayer organization memory for prior decisions about the failing
integration, then list related open issues and summarize what changed since the
last incident.
```
Pre-PR review:
```text theme={null}
Before I open this PR, check it against Corelayer with the preflight tool and
list any failure modes the org has hit before for a change like this.
```
## Local MCP
Use local MCP when your AI coding agent runs MCP servers as local stdio
processes. The local server is distributed as an npm package:
```bash theme={null}
npx -y @corelayer-ai/mcp
```
Your MCP host launches this command and communicates with it over standard input
and standard output.
Add Corelayer to your local MCP-compatible coding agent configuration:
```json theme={null}
{
"mcpServers": {
"corelayer": {
"command": "npx",
"args": ["-y", "@corelayer-ai/mcp"],
"env": {
"CORELAYER_API_KEY": "cl_key_...",
"CORELAYER_API_URL": "https://api.corelayer.com"
}
}
}
}
```
Restart your agent or editor after changing the MCP config.
## Local Authentication
The local MCP server resolves credentials in this order:
1. `CORELAYER_API_KEY`
2. the local CLI token from `~/.corelayer/config.json`
Prefer `CORELAYER_API_KEY` because it is explicit, revocable, and easier to
audit.
## Optional Local Default Group
If your local agent usually works in one Corelayer group, set
`CORELAYER_DEFAULT_GROUP` so group-scoped tools can omit `groupId`:
```json theme={null}
{
"mcpServers": {
"corelayer": {
"command": "npx",
"args": ["-y", "@corelayer-ai/mcp"],
"env": {
"CORELAYER_API_KEY": "cl_key_...",
"CORELAYER_API_URL": "https://api.corelayer.com",
"CORELAYER_DEFAULT_GROUP": "group-id"
}
}
}
}
```
For remote MCP, use the `corelayer.list_groups` discovery flow instead of a
process-level default group.
## Additional Local Tools
The local MCP package also exposes write tools for authenticated local agents:
| Tool | Type | Description |
| ----------------------------- | ----- | ------------------------------------------- |
| `corelayer.close_issue` | Write | Close one issue, optionally with feedback. |
| `corelayer.reopen_issue` | Write | Reopen one issue, optionally with feedback. |
| `corelayer.bulk_close_issues` | Write | Close multiple explicitly selected issues. |
`corelayer.bulk_close_issues` requires explicit issue IDs, caps requests at 500
IDs, and never uses a select-all mutation.
## Environment Variables
| Variable | Description | Default |
| ------------------------- | ----------------------------------------------- | --------------------------- |
| `CORELAYER_API_KEY` | Corelayer API key or token. | CLI config fallback |
| `CORELAYER_API_URL` | Corelayer API base URL. | `https://api.corelayer.com` |
| `CORELAYER_DEFAULT_GROUP` | Optional local group ID for group-scoped tools. | — |
| `CORELAYER_TIMEOUT_MS` | Corelayer API request timeout in milliseconds. | `30000` |
## Verify Local Package
Check that npm can see the package:
```bash theme={null}
npm view @corelayer-ai/mcp version
```
You can also start the local server manually:
```bash theme={null}
CORELAYER_API_KEY=cl_key_... npx -y @corelayer-ai/mcp
```
The command starts a stdio MCP server and waits for MCP JSON-RPC messages. In a
terminal it may look idle; that is expected. Your MCP host is responsible for
sending requests.
## Troubleshooting
| Symptom | Fix |
| ----------------------------------------- | ------------------------------------------------------------------------- |
| The remote connector cannot authenticate. | Confirm it sends `Authorization: Bearer ` to the MCP endpoint. |
| The connector cannot find a group. | Call `corelayer.list_groups` first and choose the matching group by name. |
| Group-scoped tools ask for `groupId`. | Use the group ID returned by `corelayer.list_groups`. |
| The local server exits immediately. | Confirm Node.js 18+ is installed and `npx -y @corelayer-ai/mcp` runs. |
| Local tools fail with missing auth. | Set `CORELAYER_API_KEY` or run `corelayer login` locally. |
| The terminal appears to hang. | This is normal; stdio MCP servers wait for JSON-RPC input from the host. |
# Corelayer CLI: Install, Auth, and Commands
Source: https://docs.corelayer.com/cli/overview
Install the Corelayer CLI to list groups, triage issues, and check integrations from the terminal, with browser login, API keys, and machine-readable JSON.
## Overview
The Corelayer CLI gives you terminal access to Corelayer groups, issues, and integrations.
Sign in from your browser, then use Corelayer from the terminal. If your organization uses a dedicated Corelayer deployment, the CLI connects to the right server automatically.
## Prerequisites
* Node.js 18+
* npm
* A Corelayer account with access to at least one organization
## Install
```bash theme={null}
npm install -g @corelayer-ai/cli
```
Verify the install:
```bash theme={null}
corelayer --version
```
## Authenticate
### Browser Login (Interactive)
```bash theme={null}
corelayer login
```
This flow:
1. Opens the Corelayer app in your browser
2. Asks you to authorize CLI access for your current organization
3. Redirects back to a temporary localhost callback used by the CLI
4. Stores your API key and server URL in `~/.corelayer/config.json`
### Environment Variable (Non-Interactive)
For CI/CD pipelines, agents, and headless environments, set the `CORELAYER_API_KEY` environment variable. No login command is required.
```bash theme={null}
export CORELAYER_API_KEY=cl_live_...
export CORELAYER_API_URL=https://api.corelayer.com
corelayer issues list --group
```
Create an API key from the Corelayer dashboard or via the API (`POST /api/v1/api-keys`), then store it as a secret in your CI/CD platform or agent runtime.
The CLI resolves credentials in this order:
1. `CORELAYER_API_KEY` environment variable (highest priority)
2. Token stored in `~/.corelayer/config.json` (from `corelayer login`)
### Pipe a Token (Non-Interactive Login)
To save an existing API key to the CLI config file without opening a browser — useful for self-hosted instances:
```bash theme={null}
printf '%s' "$CORELAYER_API_KEY" | corelayer login --with-token --api-url https://api.corelayer.com
```
This stores the token in `~/.corelayer/config.json` so subsequent commands work without the environment variable.
## Usage
The CLI documents itself. Run `corelayer --help` to see every command:
```text theme={null}
Corelayer CLI - Manage groups, issues, and integrations from your terminal
USAGE:
corelayer [global options] [command options]
COMMANDS:
login Authenticate with Corelayer (opens browser)
logout Sign out and clear local credentials
groups List and inspect groups
issues List, inspect, and manage issues
preflight Check a change against org memory before you push
integrations List integrations for a group
config Read and write local CLI config
install-skill Install the Corelayer agent skill
uninstall-skill Remove the Corelayer agent skill
GLOBAL OPTIONS:
--json Output as JSON for scripting
-q, --quiet Suppress non-essential output
--api-url Override the configured API server
--no-color Disable colored output
-h, --help Print help
-v, --version Print version
ENVIRONMENT VARIABLES:
CORELAYER_API_KEY API key for non-interactive auth (skips login)
CORELAYER_API_URL Server URL (default: https://api.corelayer.com)
CORELAYER_AUTH_URL Auth server URL (default: https://app.corelayer.com)
Run 'corelayer --help' for more information on a command.
```
Pass `--help` to any subcommand for its specific flags and examples:
```bash theme={null}
corelayer issues --help
corelayer issues list --help
```
### Quick Tour
A typical first session looks like:
```bash theme={null}
corelayer groups list --json
corelayer config set default-group
corelayer issues list --status Open
corelayer issues get --json
corelayer issues diff --duration 2hours --limit 50 --json
```
## Issue Lookup
Use `issues get` to inspect a single issue by either its UUID or its slug:
```bash theme={null}
corelayer issues get --json
corelayer issues get --json
```
Slugs are useful when an issue has been copied from the Corelayer app, a customer report, or an agent summary. The JSON response includes the issue title, status, severity, root cause, next steps, trace context, and event timeline when available.
## Issue Diffing
Use `issues diff` to answer what changed after a deploy, merge, or investigation window.
Diff from an exact timestamp:
```bash theme={null}
corelayer issues diff --group --since 2026-06-04T20:00:00Z --json
```
Diff over a relative duration:
```bash theme={null}
corelayer issues diff --group --duration 2hours --limit 50 --json
```
If you have a default group configured, you can omit `--group`:
```bash theme={null}
corelayer config set default-group
corelayer issues diff --duration 2hours --json
```
The diff response is paginated and includes:
* `since` - the timestamp used for the diff window
* `issues` - issues updated or seen since that timestamp
* `total` - total matching issues
* `page` - current page number
* `limit` - page size
Use `--limit ` and `--page ` for pagination. The default limit is `20`, and the maximum limit is `100`.
## Preflight
Use `preflight` to check a change against your organization's memory before opening a pull request. It returns the failure modes and things to double-check that the org has hit before for a change like this — grounded in [organization memory](/memory/overview#preflight-checking-a-change-before-you-ship).
Run it inside a repository with no arguments — it derives the PR context from the current branch (repo from the git remote, title/description from commits and changed files since the base branch):
```bash theme={null}
corelayer preflight
```
Override any piece, include the diff, or emit JSON:
```bash theme={null}
corelayer preflight --diff
corelayer preflight --base develop
corelayer preflight --title "Add Redis cache" --description "Caches payment lookups" --repo payments-api
corelayer preflight --json
```
Each check names the memory behind it, its severity, and how often the org has seen it; an empty result means memory had nothing relevant to flag. `--json` returns `checks` plus `consideredCount` and `pulledCount`. Preflight reads memory and is advisory — it never blocks a push.
## Global Flags
The CLI supports these global flags:
* `--json` for machine-readable output
* `--quiet` or `-q` to suppress success messages
* `--api-url ` to override the configured API server
* `--no-color` to disable ANSI color output
## Environment Variables
| Variable | Description | Default |
| -------------------- | ---------------------------------------------- | --------------------------- |
| `CORELAYER_API_KEY` | API key for non-interactive auth (skips login) | — |
| `CORELAYER_API_URL` | Server URL | `https://api.corelayer.com` |
| `CORELAYER_AUTH_URL` | Auth server URL for browser login | `https://app.corelayer.com` |
## Dedicated Deployments
For browser login, you do not need to manually choose the API server. Corelayer returns the correct `server_url` during authorization and the CLI stores it in `~/.corelayer/config.json`.
Use `--api-url` only when:
* you are doing manual login with an auth code
* you are testing against a local or non-default environment
* you explicitly want to override the stored server URL for one command
## Using the CLI with AI Agents
### Authentication for Agents
Agents should authenticate via the `CORELAYER_API_KEY` environment variable — not `corelayer login`. This follows the same pattern as `GH_TOKEN` for GitHub CLI, `VERCEL_TOKEN` for Vercel, and `STRIPE_API_KEY` for Stripe.
```bash theme={null}
export CORELAYER_API_KEY=cl_live_...
export CORELAYER_API_URL=https://api.corelayer.com
```
No login command is needed. The CLI reads the environment variable automatically.
### General Best Practices
1. Set `CORELAYER_API_KEY` and `CORELAYER_API_URL` in the agent's environment
2. Prefer `--json` when an agent needs to read the output
3. Set `default-group` if the agent will make repeated issue or integration calls
This docs repo includes a reusable agent instruction file at `agents/corelayer-cli.md`.
### Command Types
Agents should treat CLI commands in three categories:
#### 1. Read-Only Commands
These are safe to use for discovery, triage, and reporting:
* `corelayer groups list`
* `corelayer issues list`
* `corelayer issues get`
* `corelayer issues diff`
* `corelayer issues summary`
* `corelayer integrations list`
* `corelayer config get`
* `corelayer preflight`
Best practice:
* Prefer `--json` when an agent needs to reason over the output
* Use `corelayer groups list --json` first if the correct group is not known
* Set `default-group` before repeated issue or integration reads
#### 2. Local State Commands
These change the local CLI session or local config, not Corelayer data on the server:
* `corelayer login`
* `corelayer logout`
* `corelayer config set default-group `
* `corelayer config set api-url `
Best practice:
* `corelayer login` is fine when the user is actively trying to authenticate
* use `corelayer config set default-group` when the user will run repeated commands against the same group
* avoid changing `api-url` unless the user explicitly wants a different environment
* avoid `logout` unless the user asks for it or the workflow clearly requires resetting auth
#### 3. Write and Update Commands
These change data or issue state on the Corelayer server and should be used carefully:
* `corelayer issues close --feedback "..."`
* `corelayer issues bulk-close --group --last-seen-before-or-on 14days --feedback "..."`
* `corelayer issues reopen `
* `corelayer issues delete --yes`
When an agent or script needs to close a large stale set, prefer `bulk-close` over looping `issues close` calls. Bulk close is the intended path for large cleanups and avoids 429 rate limits from repeated single-issue mutations.
Best practice:
* ask for explicit approval before running any of these commands
* include a short, accurate reason when closing an issue
* prefer `close` or `reopen` over `delete`
* only use `delete --yes` when the user has clearly requested deletion
* if the user is unsure, show the issue first with `corelayer issues get --json`
### Recommended Agent Workflows
#### Investigate issues in one group
```bash theme={null}
corelayer groups list --json
corelayer config set default-group
corelayer issues list --json --status Open
corelayer issues get --json
corelayer issues diff --duration 2hours --limit 50 --json
```
#### Review integrations for a group
```bash theme={null}
corelayer integrations list --json --group
```
#### Summarize current issue health
```bash theme={null}
corelayer issues summary --group
```
#### Preflight a change before opening a PR
```bash theme={null}
corelayer preflight
```
Run this when you're about to open a pull request — it derives the change from the current branch and surfaces failure modes the org has hit before. Present any results as reminders to double-check; if it returns nothing, say memory had nothing to flag.
Use it as a project instruction, repo memory, or agent prompt snippet:
```md theme={null}
When you need Corelayer data, prefer the `corelayer` CLI over raw HTTP requests.
- Run `corelayer groups list --json` first if the target group is unknown.
- If multiple commands will use the same group, run `corelayer config set default-group `.
- Prefer `corelayer issues list --json`, `corelayer issues get --json`, `corelayer issues diff --duration 2hours --json`, and `corelayer integrations list --json`.
- When about to open a pull request, run `corelayer preflight` and surface anything it flags as reminders to double-check.
- Treat `corelayer issues close`, `corelayer issues bulk-close`, `corelayer issues reopen`, and `corelayer issues delete --yes` as write operations that require explicit user approval.
- Treat `corelayer config set` and `corelayer logout` as local state changes; use them only when the workflow clearly calls for them.
- If the user is not authenticated, check if `CORELAYER_API_KEY` is set; if not, ask them to run `corelayer login` or set the environment variable.
```
This works well across agent tools. The underlying guidance is agent-agnostic rather than tied to any single coding assistant. If a specific agent supports installable skills or command packs, wrap the same instructions in that tool's native format instead of maintaining separate guidance by hand.
## Troubleshooting
### Browser Login Does Not Open
Copy the URL printed by `corelayer login` and open it manually in your browser.
### Callback Fails on `127.0.0.1`
Use manual login:
```bash theme={null}
corelayer login --code --api-url
```
### Wrong Organization or Server
Log in again while the correct organization is active in the Corelayer app. The browser flow will return the correct server URL for that organization.
### API Calls Fail After Switching Environments
Check the stored API server:
```bash theme={null}
corelayer config get api-url
```
Then either:
* run `corelayer login` again
* or override the server for a command with `--api-url `
Need help? [Contact support](mailto:support@corelayer.com) for assistance with the Corelayer CLI.
# What is Corelayer? AI SRE for Production
Source: https://docs.corelayer.com/index
Corelayer is an AI SRE and AI on-call platform that root-causes production incidents, cuts alert noise, and suggests fixes in minutes. Updated 2026.
## AI for Managing Production
Corelayer continuously monitors production logs, metrics, and data for issues and uses agents to debug and suggest fixes in minutes.
It's designed to handle sensitive data, offering flexible deployment and LLM inference options, making Corelayer particularly well-suited for data-intensive, regulated industries like finance, healthcare, and insurance.
## Key Features
* **Automated Monitoring**: Continuously monitors your production systems
* **Rich Context**: Integrates with your infrastructure, observability, and data stack
* **Environment Awareness**: Infers the environment associated with an issue and considers it during investigation and impact assessment
* **Data Anomaly Detection**: Statistical anomaly detection for silent data correctness issues
* **Alert De-Noising**: Filters out false positives and groups related issues together
* **Root-Cause Analysis**: Identifies and root-causes issues in minutes
* **Code Fixes**: Suggests issue remediations and creates PRs to fix bugs
* **Auditable**: Documents investigation steps and cites relevant sources like logs
* **Learns Over Time**: Corelayer references past issues and takes human feedback to improve over time
* **CLI Access**: Query groups, issues, and integrations from the terminal with the Corelayer CLI
## Environment-Aware Analysis
Corelayer infers the environment associated with an issue from the available context and considers it when investigating the issue and assessing its impact. This helps distinguish issues across environments such as production, staging, and development.
To see the environments Corelayer has detected, open **Settings → Environments**. The **Detected Environments** list shows each environment, its aliases, and whether it is production or pre-production.
![Corelayer Settings with Environments selected and detected prod, dev, and preview environments, their aliases, and production classifications.]()
You can also use environment and severity to route notifications to the appropriate [Slack channels](/integrations/slack#route-notifications-by-environment-and-severity).
## Developer Workflows
If you prefer working from the terminal, start with the [Corelayer CLI](/cli/overview). It supports browser-based login, API-key-backed requests, and a machine-readable `--json` mode that works well with AI agents.
# Apache Airflow Integration: Monitor DAGs
Source: https://docs.corelayer.com/integrations/airflow
Connect Airflow to Corelayer to monitor DAG runs and debug workflow failures, with AI agents that trace pipeline breakages to their upstream root cause.
## Prerequisites
* An Apache Airflow deployment (Self-Hosted, Amazon MWAA, or Astronomer)
* Admin access to your Airflow instance
* API access enabled on your Airflow deployment
## Step-by-Step Setup
### 1. Navigate to Integrations
In your Corelayer dashboard, go to the **Integrations** page.
### 2. Add Airflow Integration
Click the **Add Integration** button and select **Apache Airflow** from the list of available integrations.
### 3. Select Deployment Type
Choose your Airflow deployment type:
* **Self-Hosted** — Standard Airflow deployment managed by your team
* **Amazon MWAA** — Managed Workflows for Apache Airflow on AWS
* **Astronomer** — Airflow managed by Astronomer
### 4. Configure Credentials
Depending on your deployment type:
**Self-Hosted:**
* Enter your Airflow **Base URL** (e.g., `https://airflow.yourcompany.com`)
* Provide authentication credentials (username/password or API token)
**Amazon MWAA:**
* Enter your **MWAA Environment Name**
* Specify the AWS **Region**
* Ensure Corelayer's AWS integration has access to the MWAA environment
**Astronomer:**
* Enter your Astronomer **API URL**
* Provide your **Organization ID** and **Deployment ID**
* Enter your Astronomer **API Key**
### 5. Test Connection
Click **Test Connection** to verify that Corelayer can access your Airflow instance.
### 6. Select DAGs
Once connected, select which DAGs you want Corelayer to monitor:
* Browse the list of available DAGs
* Check the boxes next to the DAGs you want to include
* Click **Update Selection**
## What Corelayer Can Do With Airflow
Once connected, Corelayer will:
* Monitor selected DAGs for task failures and errors
* Pull DAG run and task execution context for debugging
* Analyze pipeline failures and suggest remediation steps
* Correlate Airflow issues with other integrations for root-cause analysis
## Managing Your Integration
### Disconnecting
To disconnect your Airflow integration:
1. Navigate to Settings > Integrations
2. Find your Airflow integration and click **Uninstall**
3. Confirm the uninstallation
4. Optionally, revoke the API credentials you created for Corelayer
## Troubleshooting
### Integration Not Working?
* Verify your Airflow instance is accessible from the internet (or through your network configuration)
* Ensure the API credentials are correct and have not expired
* Check that the Airflow REST API is enabled on your instance
* For MWAA, confirm the IAM role has the required permissions
* For Astronomer, verify the API key and deployment ID are correct
Need help? [Contact support](mailto:support@corelayer.com) for assistance with your Airflow integration.
# AWS Integration: CloudWatch, RDS, and S3
Source: https://docs.corelayer.com/integrations/aws
Connect AWS to Corelayer to monitor CloudWatch logs, RDS, and S3, with AI agents that root-cause incidents across your cloud infrastructure in minutes.
## Prerequisites
* An AWS account with the services you want to monitor (CloudWatch, RDS, S3)
* Permissions to create IAM roles and policies in your AWS account
## Step-by-Step Setup
### 1. Navigate to Integrations
In your Corelayer dashboard, go to the **Integrations** page.
### 2. Add AWS Integration
Click the **Add Integration** button and select **AWS** from the list of available integrations.
### 3. Select Services
Choose which AWS services you want Corelayer to monitor:
* **CloudWatch** — Log group monitoring and analysis
* **RDS** — Database instance monitoring
* **S3** — Bucket access for relevant data
### 4. Enter Your AWS Account Number
Provide your 12-digit AWS account number. Corelayer will generate an external ID for secure cross-account access.
### 5. Create the IAM Policy
Corelayer will provide a JSON policy document. Create this policy in your AWS IAM console:
1. Go to **IAM > Policies > Create Policy**
2. Select the **JSON** tab
3. Paste the provided policy document
4. Name the policy (e.g., `CorelayerPolicy`)
### 6. Create the IAM Role
Create an IAM role for Corelayer to assume:
1. Go to **IAM > Roles > Create Role**
2. Select **Custom trust policy**
3. Paste the trust policy provided by Corelayer (includes the external ID)
4. Attach the policy you created in the previous step
5. Name the role (e.g., `CorelayerRole`)
### 7. Enter the Role ARN
Copy the ARN of the role you created and paste it into the Corelayer setup form. Click **Test Connection** to verify access.
### 8. Select Resources
Once connected, select the specific resources you want Corelayer to monitor:
* **CloudWatch Log Groups** — Choose which log groups to include
* **RDS Instances** — Select database instances to monitor
* **S3 Buckets** — Pick buckets relevant to your services
## What Corelayer Can Do With AWS
Once connected, Corelayer will:
* Monitor CloudWatch log groups for errors and anomalies
* Query RDS database instances to gather context during debugging
* Access S3 buckets for configuration and data context
* Correlate AWS resource data with other integrations to identify root causes
## Managing Your Integration
### Disconnecting
To disconnect your AWS integration:
1. Navigate to Settings > Integrations
2. Find your AWS integration and click **Uninstall**
3. Confirm the uninstallation
4. Optionally, delete the IAM role and policy from your AWS account
## Troubleshooting
### Integration Not Working?
* Verify the IAM role ARN is correct
* Ensure the trust policy includes the correct external ID
* Check that the IAM policy grants the required permissions
* Confirm the role can be assumed by Corelayer's AWS account
* Verify the selected resources exist and are accessible
Need help? [Contact support](mailto:support@corelayer.com) for assistance with your AWS integration.
# ClickHouse Integration: Query Analytics Data
Source: https://docs.corelayer.com/integrations/clickhouse
Connect ClickHouse to Corelayer so AI agents securely query your analytics data during investigations, root-causing data correctness issues alongside logs.
## Prerequisites
* A ClickHouse instance (self-hosted or ClickHouse Cloud)
* Permission to create users and grant table access in your ClickHouse instance
## Step-by-Step Setup
### 1. Navigate to Integrations
In your Corelayer dashboard, go to the **Integrations** page.
### 2. Add ClickHouse Integration
Click the **Add Integration** button and select **ClickHouse** from the list of available integrations.
### 3. Create a Dedicated ClickHouse User
For security, create a dedicated read-only user for Corelayer. Run the following SQL in your ClickHouse instance:
```sql theme={null}
CREATE USER corelayer IDENTIFIED BY '';
```
### 4. Enter Connection Details
Provide the following connection details:
* **Host** — Your ClickHouse server hostname
* **Port** — The connection port (default: 8443 for HTTPS, 9440 for native TLS)
* **Protocol** — HTTP or Native protocol
* **Username** — The dedicated user you created (e.g., `corelayer`)
* **Password** — The password for the user
### 5. Test Connection
Click **Test Connection** to verify that Corelayer can connect to your ClickHouse instance.
### 6. Select Tables
Once connected, Corelayer will discover your databases and tables:
* Browse the list of available databases and tables
* Select the tables you want Corelayer to have access to
* Click **Update Selection**
### 7. Grant Table Access
After selecting tables, grant read access to the Corelayer user. Corelayer will provide the SQL commands:
```sql theme={null}
GRANT SELECT ON . TO corelayer;
```
Run these commands in your ClickHouse instance for each selected table.
## What Corelayer Can Do With ClickHouse
Once connected, Corelayer will:
* Query your selected tables to gather context during debugging
* Analyze data patterns to identify anomalies related to reported issues
* Correlate database data with logs and errors from other integrations
## Managing Your Integration
### Disconnecting
To disconnect your ClickHouse integration:
1. Navigate to Settings > Integrations
2. Find your ClickHouse integration and click **Uninstall**
3. Confirm the uninstallation
4. Optionally, drop the dedicated Corelayer user from your ClickHouse instance
## Troubleshooting
### Integration Not Working?
* Verify the connection details (host, port, protocol) are correct
* Ensure the ClickHouse user has been created and the password is correct
* Check that `SELECT` permissions have been granted on the selected tables
* Confirm your ClickHouse instance is accessible from the network
* Verify TLS/SSL settings if using encrypted connections
Need help? [Contact support](mailto:support@corelayer.com) for assistance with your ClickHouse integration.
# Cloudflare Integration: Debug Workers
Source: https://docs.corelayer.com/integrations/cloudflare
Connect Cloudflare to Corelayer to monitor Workers and debug edge applications, with AI agents that correlate edge errors against your wider production stack.
## Prerequisites
* A Cloudflare account with Workers deployed
* Your Cloudflare **Account ID** (found in the Cloudflare dashboard under any domain overview or the Workers section)
* Permission to create API tokens
## Step-by-Step Setup
### 1. Navigate to Integrations
In your Corelayer dashboard, go to the **Integrations** page.
### 2. Add Cloudflare Integration
Click the **Add Integration** button and select **Cloudflare** from the list of available integrations.
### 3. Enter Your Account ID
Provide your 32-character Cloudflare Account ID. You can find this in your Cloudflare dashboard under **Workers & Pages > Overview** or on any domain's overview page.
### 4. Create an API Token
In your Cloudflare dashboard:
1. Go to **My Profile > API Tokens**
2. Click **Create Token**
3. Configure the token with the permissions Corelayer requires (read access to Workers)
4. Copy the generated token and paste it into the Corelayer setup form
### 5. Test Connection
Click **Test Connection** to verify that Corelayer can access your Cloudflare account.
### 6. Select Workers
Once connected, select which Cloudflare Workers you want Corelayer to monitor.
## What Corelayer Can Do With Cloudflare
Once connected, Corelayer will:
* Monitor your Cloudflare Workers for errors and performance issues
* Pull Worker logs and execution data for debugging context
* Correlate Cloudflare data with other integrations for root-cause analysis
## Managing Your Integration
### Disconnecting
To disconnect your Cloudflare integration:
1. Navigate to Settings > Integrations
2. Find your Cloudflare integration and click **Uninstall**
3. Confirm the uninstallation
4. Optionally, revoke the API token in your Cloudflare dashboard
## Troubleshooting
### Integration Not Working?
* Verify your Account ID is correct (must be a 32-character hexadecimal string)
* Ensure the API token has the required permissions
* Check that the token has not expired or been revoked
* Confirm your Workers are deployed and active
Need help? [Contact support](mailto:support@corelayer.com) for assistance with your Cloudflare integration.
# Datadog Integration: Add an AI SRE Layer
Source: https://docs.corelayer.com/integrations/datadog
Keep Datadog for dashboards and add Corelayer as the AI SRE layer that investigates what it surfaces, correlating logs, services, and metrics automatically.
## Prerequisites
* A Datadog account with log indexing and metrics enabled
* Permissions to create API keys and Application keys in Datadog
## Step-by-Step Setup
### 1. Navigate to Integrations
In your Corelayer dashboard, go to the **Integrations** page.
### 2. Add Datadog Integration
Click the **Add Integration** button and select **Datadog** from the list of available integrations.
### 3. Enter Organization Details
Provide the following:
* **Organization Name** — Your Datadog organization name
* **App URL** — Your Datadog application URL (e.g., `https://app.datadoghq.com`)
### 4. Create an API Key
In your Datadog account:
1. Go to **Organization Settings > API Keys**
2. Click **New Key**
3. Name the key (e.g., `Corelayer`)
4. Copy the key and paste it into the Corelayer setup form
### 5. Create an Application Key
In your Datadog account:
1. Go to **Organization Settings > Application Keys**
2. Click **New Key**
3. Name the key (e.g., `Corelayer`)
4. Ensure the key has the following scopes:
* `logs_read_data`
* `logs_read_index_data`
* `logs_read_config`
* `metrics_read`
5. Copy the key and paste it into the Corelayer setup form
### 6. Test Connection
Click **Test Connection** to verify that Corelayer can access your Datadog account.
### 7. Select Resources
Once connected, choose which resources to monitor:
* **Log Services** — Select the services whose logs Corelayer should analyze
* **Log Indexes** — Choose which log indexes to query
* **Metrics** — Select metrics relevant to your services
## What Corelayer Can Do With Datadog
Once connected, Corelayer will:
* Query logs from your selected services and indexes to gather context during debugging
* Monitor metrics for anomalies and correlate with error events
* Combine Datadog observability data with other integrations for comprehensive root-cause analysis
## Managing Your Integration
### Disconnecting
To disconnect your Datadog integration:
1. Navigate to Settings > Integrations
2. Find your Datadog integration and click **Uninstall**
3. Confirm the uninstallation
4. Optionally, revoke the API and Application keys in your Datadog account
## Troubleshooting
### Integration Not Working?
* Verify your API key and Application key are correct
* Ensure the Application key has the required scopes (`logs_read_data`, `logs_read_index_data`, `logs_read_config`, `metrics_read`)
* Check that your Datadog App URL matches your region
* Confirm that the services and indexes you selected are active and receiving data
Need help? [Contact support](mailto:support@corelayer.com) for assistance with your Datadog integration.
# GCP Integration: Cloud Run, GKE, Functions
Source: https://docs.corelayer.com/integrations/gcp
Connect Google Cloud to Corelayer to monitor Cloud Run, Cloud Functions, and GKE, with AI agents that investigate and root-cause production incidents.
## Prerequisites
* A GCP project with the services you want to monitor
* Permissions to create Workload Identity Federation pools, service accounts, and manage IAM in your GCP project
* Your GCP **Project ID** and **Project Number**
## Step-by-Step Setup
### 1. Navigate to Integrations
In your Corelayer dashboard, go to the **Integrations** page.
### 2. Add GCP Integration
Click the **Add Integration** button and select **GCP** from the list of available integrations.
### 3. Enter Project Details
Provide your GCP **Project ID** and **Project Number**. You can find these in the GCP Console under **Project Settings**.
### 4. Enable Required APIs
Enable the following APIs in your GCP project (Corelayer will list the exact APIs based on your selected services):
* Cloud Resource Manager API
* IAM Service Account Credentials API
* Any service-specific APIs (e.g., Cloud Run Admin API, Cloud Functions API)
### 5. Create a Workload Identity Federation Pool
Follow the provided commands to create a WIF pool in your GCP project:
1. Create the Workload Identity Pool
2. Create an OIDC Provider within the pool
3. Configure attribute mappings for Corelayer's identity
### 6. Create a Service Account
Create a service account for Corelayer:
1. Create the service account in your GCP project
2. Grant the necessary roles (viewer/reader roles for the services you want to monitor)
3. Allow Corelayer to impersonate the service account via the WIF pool
### 7. Test Connection
Enter the service account email and WIF configuration details, then click **Test Connection** to verify access.
### 8. Select Resources
Once connected, choose which GCP resources to monitor:
* **Cloud Run** — Select Cloud Run services
* **Cloud Functions** — Select functions to monitor
* **GKE** — Select Kubernetes clusters
* **App Engine** — Select App Engine applications
* **Compute Engine** — Select VM instances
## What Corelayer Can Do With GCP
Once connected, Corelayer will:
* Monitor your selected GCP services for errors and issues
* Query Cloud Logging for relevant log entries during debugging
* Access Cloud SQL instances for database context
* Correlate GCP service data with other integrations for root-cause analysis
## Managing Your Integration
### Disconnecting
To disconnect your GCP integration:
1. Navigate to Settings > Integrations
2. Find your GCP integration and click **Uninstall**
3. Confirm the uninstallation
4. Optionally, delete the service account and WIF pool from your GCP project
## Troubleshooting
### Integration Not Working?
* Verify your Project ID and Project Number are correct
* Ensure the required APIs are enabled in your GCP project
* Check that the service account has the correct IAM roles
* Confirm the WIF pool and OIDC provider are configured correctly
* Verify that Corelayer's identity can impersonate the service account
Need help? [Contact support](mailto:support@corelayer.com) for assistance with your GCP integration.
# GitHub Integration: Code Context and PRs
Source: https://docs.corelayer.com/integrations/github
Connect GitHub to Corelayer for repository context during investigations, letting AI agents trace incidents to the responsible code and open fix pull requests.
## Prerequisites
* A GitHub account with repositories you want to connect
* Admin or Owner permissions for the GitHub organization or repositories
## Step-by-Step Setup
### 1. Navigate to Integrations
In your Corelayer dashboard, go to the **Integrations** page.
### 2. Add GitHub Integration
Click the **Add Integration** button and select **GitHub** from the list of available integrations.
### 3. Configure Preferences
Before connecting, choose your preferences:
* **Code Indexing** — Allow Corelayer to index your repositories for richer code context during debugging
* **PR Creation** — Allow Corelayer to create pull requests with suggested fixes
### 4. Install the GitHub App
Click **Connect to GitHub**. You'll be redirected to GitHub to install the Corelayer GitHub App:
1. Select the organization or account to install on
2. Choose which repositories to grant access to (all or select specific ones)
3. Click **Install & Authorize**
### 5. Verify Connection
Once redirected back to Corelayer, your GitHub integration should appear as **Connected** in the integrations dashboard. Your selected repositories will be listed.
## What Corelayer Can Do With GitHub
Once connected, Corelayer will:
* Pull code context from your repositories when debugging issues
* Index repository code for faster and more accurate root-cause analysis
* Optionally create pull requests with suggested code fixes
* Correlate code changes with errors from other integrations
## Managing Your Integration
### Disconnecting
To disconnect your GitHub integration:
1. Navigate to Settings > Integrations
2. Find your GitHub integration and click **Uninstall**
3. Confirm the uninstallation
4. Optionally, uninstall the Corelayer GitHub App from your GitHub organization settings
## Troubleshooting
### Integration Not Working?
* Verify the GitHub App is installed on the correct organization
* Ensure the app has access to the repositories you want to monitor
* Check that your GitHub account has sufficient permissions
* Try reinstalling the GitHub App if repositories are not appearing
Need help? [Contact support](mailto:support@corelayer.com) for assistance with your GitHub integration.
# Merge Integration: HR and HCM Data Context
Source: https://docs.corelayer.com/integrations/merge
Connect Merge to Corelayer to bring HR and HCM platform data into investigations, giving AI agents the context to debug integration and sync failures.
## Prerequisites
* A Merge account with linked HR/HCM accounts
* An API key from your Merge dashboard
* Account tokens for the linked accounts you want to connect
## Step-by-Step Setup
### 1. Navigate to Integrations
In your Corelayer dashboard, go to the **Integrations** page.
### 2. Add Merge Integration
Click the **Add Integration** button and select **Merge** from the list of available integrations.
### 3. Select Region
Choose the region that matches your Merge account:
* **US** — United States
* **EU** — Europe
* **APAC** — Asia-Pacific
### 4. Enter Your API Key
In your Merge dashboard:
1. Navigate to your API key settings
2. Copy your API key
3. Paste it into the Corelayer setup form
### 5. Test Connection
Click **Test Connection** to verify that Corelayer can access your Merge account.
### 6. Select Linked Accounts
Once connected, Corelayer will display your available linked accounts:
* Browse the list of linked HR/HCM accounts
* Select the accounts you want Corelayer to access
### 7. Verify Account Tokens
For each selected linked account, provide the account token:
* Enter tokens manually for each account, or
* Use the **CSV import** option to bulk-import tokens using the provided template
### 8. Configure Webhook (Optional)
Optionally, set up a webhook to receive real-time updates from Merge:
1. Corelayer will provide a webhook URL
2. Configure this URL in your Merge dashboard
3. Enter the webhook signing secret in Corelayer
## What Corelayer Can Do With Merge
Once connected, Corelayer will:
* Access HR/HCM platform data through Merge's unified API
* Use employee and organizational data as context during debugging
* Correlate HR system data with other integrations for comprehensive analysis
## Managing Your Integration
### Disconnecting
To disconnect your Merge integration:
1. Navigate to Settings > Integrations
2. Find your Merge integration and click **Uninstall**
3. Confirm the uninstallation
4. Optionally, revoke the API key in your Merge dashboard
## Troubleshooting
### Integration Not Working?
* Verify your API key is correct and active
* Ensure the selected region matches your Merge account configuration
* Check that the account tokens are valid for each linked account
* Confirm your linked accounts are active in Merge
Need help? [Contact support](mailto:support@corelayer.com) for assistance with your Merge integration.
# Oracle Cloud (OCI) Integration and Logs
Source: https://docs.corelayer.com/integrations/oci
Connect Oracle Cloud Infrastructure to Corelayer to monitor OCI log groups, with AI agents that root-cause production incidents across hybrid environments.
## Prerequisites
* An Oracle Cloud Infrastructure (OCI) account
* Permission to create users, API keys, and manage log groups in your OCI tenancy
* The following OCI identifiers:
* **Tenancy OCID**
* **User OCID**
* **Compartment OCID**
## Step-by-Step Setup
### 1. Navigate to Integrations
In your Corelayer dashboard, go to the **Integrations** page.
### 2. Add OCI Integration
Click the **Add Integration** button and select **Oracle Cloud (OCI)** from the list of available integrations.
### 3. Create an API Signing Key
In your OCI console:
1. Navigate to **Identity > Users > Your User > API Keys**
2. Click **Add API Key**
3. Generate or upload a key pair
4. Copy the **Fingerprint** of the key
5. Download or copy the **Private Key (PEM)**
### 4. Enter Credentials
Provide the following details:
* **Tenancy OCID** — Your OCI tenancy identifier (e.g., `ocid1.tenancy.oc1..xxxx`)
* **User OCID** — The OCI user identifier (e.g., `ocid1.user.oc1..xxxx`)
* **Fingerprint** — The API key fingerprint
* **Private Key (PEM)** — The private key contents
* **Region** — Your OCI region (e.g., `us-ashburn-1`)
* **Compartment OCID** — The compartment to monitor (e.g., `ocid1.compartment.oc1..xxxx`)
### 5. Test Connection
Click **Test Connection** to verify that Corelayer can authenticate with your OCI tenancy.
### 6. Select Log Groups
Once connected, select which OCI log groups you want Corelayer to monitor:
* Browse the list of available log groups in your compartment
* Check the boxes next to the log groups you want to include
* Click **Update Selection**
## What Corelayer Can Do With OCI
Once connected, Corelayer will:
* Monitor selected log groups for errors and anomalies
* Query OCI logs to gather context during debugging
* Correlate OCI log data with other integrations for root-cause analysis
## Managing Your Integration
### Disconnecting
To disconnect your OCI integration:
1. Navigate to Settings > Integrations
2. Find your OCI integration and click **Uninstall**
3. Confirm the uninstallation
4. Optionally, delete the API signing key from your OCI user settings
## Troubleshooting
### Integration Not Working?
* Verify all OCIDs (tenancy, user, compartment) are correct and properly formatted
* Ensure the API signing key fingerprint matches the key uploaded in OCI
* Check that the private key PEM is complete and properly formatted
* Confirm the specified region matches your OCI resources
* Verify the user has the necessary IAM policies to read log groups
Need help? [Contact support](mailto:support@corelayer.com) for assistance with your OCI integration.
# PlanetScale Integration: Debug App Data
Source: https://docs.corelayer.com/integrations/planetscale
Connect PlanetScale to Corelayer so AI agents query application data while debugging, linking database state to the production incident under investigation.
## Prerequisites
* A PlanetScale account with active databases
* Permission to create credentials in your PlanetScale database
## Step-by-Step Setup
### 1. Navigate to Integrations
In your Corelayer dashboard, go to the **Integrations** page.
### 2. Add PlanetScale Integration
Click the **Add Integration** button and select **PlanetScale** from the list of available integrations.
### 3. Select Database Engine
Choose the engine your PlanetScale database uses:
* **MySQL** — Standard PlanetScale MySQL-compatible databases
* **Postgres** — PlanetScale Postgres-compatible databases
### 4. Create PlanetScale Credentials
In your PlanetScale dashboard:
1. Go to your database
2. Navigate to **Settings > Passwords**
3. Create a new password for Corelayer with read-only access
4. Copy the connection details
### 5. Enter Connection Details
Provide the following:
* **Host** — Your PlanetScale database host
* **Database** — The database name
* **Username** — The credential username
* **Password** — The credential password
### 6. Configure Replica (Optional)
If you have a read replica, you can optionally provide replica connection details. This allows Corelayer to query your replica instead of the primary database, reducing load on production:
* **Replica Host** — Your replica hostname
* **Replica Database** — The replica database name
* **Replica Username** — Replica credentials
* **Replica Password** — Replica password
### 7. Test Connection
Click **Test Connection** to verify that Corelayer can connect to your PlanetScale database (and replica, if configured).
### 8. Select Tables
Once connected, Corelayer will discover your schemas and tables:
* Browse the list of available schemas and tables
* Select the tables you want Corelayer to have access to
* Click **Update Selection**
## What Corelayer Can Do With PlanetScale
Once connected, Corelayer will:
* Query your selected tables to gather context during debugging
* Analyze data patterns to identify anomalies related to reported issues
* Use read replicas (if configured) to avoid impacting production performance
* Correlate database data with logs and errors from other integrations
## Managing Your Integration
### Disconnecting
To disconnect your PlanetScale integration:
1. Navigate to Settings > Integrations
2. Find your PlanetScale integration and click **Uninstall**
3. Confirm the uninstallation
4. Optionally, revoke the credentials in your PlanetScale dashboard
## Troubleshooting
### Integration Not Working?
* Verify the connection details (host, database, username, password) are correct
* Ensure the credentials have read access to the selected tables
* Check that your PlanetScale database is active and accessible
* If using a replica, verify the replica connection details separately
* Confirm SSL/TLS is properly configured for your connection
Need help? [Contact support](mailto:support@corelayer.com) for assistance with your PlanetScale integration.
# Sentry Integration: AI Error Debugging
Source: https://docs.corelayer.com/integrations/sentry
Connect Sentry to Corelayer so AI agents investigate application errors automatically, correlating stack traces with logs, infrastructure, and code context.
## Prerequisites
* A Sentry account with projects you want to monitor
* Admin or Owner permissions in your Sentry organization
## Step-by-Step Setup
### 1. Navigate to Integrations
In your Corelayer dashboard, go to the **Integrations** page.
### 2. Add Sentry Integration
Click the **Add Integration** button and select **Sentry** from the list of available integrations. Click **Connect to Sentry**.
### 3. Authorize Sentry Connection
You'll be redirected to Sentry's OAuth authorization page. Click **Accept & Install** to grant Corelayer access to your Sentry organizations, projects, issues, and events.
### 4. Verify Connection
Once configured, you should see your Sentry integration listed as **Connected** in your integrations dashboard.
### 5. Configure Projects
Select which Sentry projects you want Corelayer to monitor:
* Check the boxes next to the projects you want to include
* Click **Update Selection**
## What Corelayer Can Do With Sentry
Once connected, Corelayer will:
* Listen for any new Sentry issues
* When an issue is created in a selected Sentry project, an AI agent will pull in relevant context and start debugging
* The agent will summarize the root cause of the issue and suggest and remediation steps
## Managing Your Integration
### Disconnecting
To disconnect your Sentry integration:
1. Navigate to Settings > Integrations
2. Find "Corelayer" and click **Uninstall**
3. Confirm the uninstallation
4. Corelayer will remove your Sentry data and no longer monitor your Sentry projects
## Troubleshooting
### Integration Not Working?
* Verify your Sentry organization is accessible
* Ensure you have the correct permissions in Sentry
* Check that your selected projects are active and receiving errors
* Try to uninstall from Sentry, then add then integration again from the Corelayer **Integrations** page
Need help? [Contact support](mailto:support@corelayer.com) for assistance with your Sentry integration.
# Slack Integration: Incident Notifications
Source: https://docs.corelayer.com/integrations/slack
Connect Slack to Corelayer to receive incident notifications and root-cause summaries, with routing by environment and severity.
## Prerequisites
* A Slack workspace
* Permission to install apps in your Slack workspace
## Step-by-Step Setup
### 1. Navigate to Integrations
In your Corelayer dashboard, go to the **Integrations** page.
### 2. Add Slack Integration
Click the **Add Integration** button and select **Slack** from the list of available integrations. Click **Connect to Slack**.
### 3. Authorize Slack Connection
You'll be redirected to Slack's OAuth authorization page:
1. Select the workspace you want to connect
2. Review the permissions Corelayer is requesting
3. Click **Allow** to grant access
### 4. Verify Connection
Once redirected back to Corelayer, your Slack integration should appear as **Connected** in the integrations dashboard.
### 5. Configure Channels
Select which Slack channels Corelayer should send notifications to:
* Choose existing channels from the dropdown
* Configure notification preferences per channel, including routing by environment and severity
## Route Notifications by Environment and Severity
Corelayer infers the environment associated with an issue and considers it during analysis. You can use environment and severity to route issue notifications to the Slack channels that should receive them.
Open **Integrations → Slack → Settings**. Under **Alerts → Routing rules**, expand an existing rule or click **Add rule**. Use **Environment** and **Severity** to select the matching criteria, then choose the destination **Channel**.
![Slack integration Settings with a Production routing rule expanded, showing prod selected under Environment, Medium under Severity, and corelayer-alerts as the Channel.]()
Rules are checked from top to bottom, and the first matching rule sends the alert. For example:
* Route critical production issues to your on-call channel
* Route staging issues to a staging channel
* Route development issues to a development channel
Choose the environments and severities that each team needs to follow. Make sure the Corelayer bot has been invited to every destination channel.
## What Corelayer Can Do With Slack
Once connected, Corelayer will:
* Send real-time notifications when issues are detected
* Post debugging summaries and root-cause analysis to your channels
* Deliver digest messages with aggregated issue reports
* Create scheduled tasks from Slack, including recurring checks and one-shot reminders
* Route issue notifications to your configured channels based on environment and severity
## Scheduled Tasks From Slack
You can ask Corelayer in Slack to run a task on a schedule and post the result back to the same channel.
Examples:
* "Every weekday at 9am, post a summary of open critical issues"
* "Every hour, check whether new high-severity issues appeared"
* "Remind me in 20 minutes to check this issue again"
Corelayer supports recurring schedules, fixed intervals, and one-shot reminders. If your request uses a local time, include the timezone so Corelayer can schedule it correctly.
Scheduled runs are read-only: they can investigate, summarize, and report back to Slack, but they cannot change settings or create additional scheduled tasks.
## Managing Your Integration
### Disconnecting
To disconnect your Slack integration:
1. Navigate to Settings > Integrations
2. Find your Slack integration and click **Uninstall**
3. Confirm the uninstallation
4. Optionally, remove the Corelayer app from your Slack workspace settings
## Troubleshooting
### Integration Not Working?
* Verify the Corelayer app is installed in your Slack workspace
* Ensure the bot has been invited to the channels you've configured
* Check that your Slack workspace permissions allow third-party app installations
* If an issue notification is missing, check that its environment and severity match the routing criteria for the channel
* Try reinstalling the integration if notifications are not appearing
Need help? [Contact support](mailto:support@corelayer.com) for assistance with your Slack integration.
# Microsoft Teams Integration and Alerts
Source: https://docs.corelayer.com/integrations/teams
Connect Microsoft Teams to Corelayer for real-time incident notifications and completed root-cause summaries delivered into your existing team channels.
## Prerequisites
* A Microsoft Teams workspace
* Permission to install apps in your Teams organization
## Step-by-Step Setup
### 1. Navigate to Integrations
In your Corelayer dashboard, go to the **Integrations** page.
### 2. Add Microsoft Teams Integration
Click the **Add Integration** button and select **Microsoft Teams** from the list of available integrations. Click **Connect to Teams**.
### 3. Authorize Teams Connection
You'll be redirected to Microsoft's OAuth authorization page:
1. Sign in with your Microsoft account
2. Review the permissions Corelayer is requesting
3. Click **Accept** to grant access
### 4. Verify Connection
Once redirected back to Corelayer, your Teams integration should appear as **Connected** in the integrations dashboard.
### 5. Configure Channels
Select which Teams channels Corelayer should send notifications to:
* Browse your Teams and channels
* Select the channels where you want to receive notifications
## What Corelayer Can Do With Microsoft Teams
Once connected, Corelayer will:
* Send real-time notifications when issues are detected
* Post debugging summaries and root-cause analysis to your channels
* Deliver rich adaptive card messages with actionable information
* Route notifications to the channels you configured
## Managing Your Integration
### Disconnecting
To disconnect your Microsoft Teams integration:
1. Navigate to Settings > Integrations
2. Find your Teams integration and click **Uninstall**
3. Confirm the uninstallation
4. Optionally, remove the Corelayer app from your Teams admin settings
## Troubleshooting
### Integration Not Working?
* Verify the Corelayer app is authorized in your Teams organization
* Ensure the bot has access to the channels you've configured
* Check that your Teams admin policies allow third-party app installations
* Try reinstalling the integration if notifications are not appearing
Need help? [Contact support](mailto:support@corelayer.com) for assistance with your Microsoft Teams integration.
# Trigger.dev Integration: Debug Background Jobs
Source: https://docs.corelayer.com/integrations/trigger-dev
Connect Trigger.dev to Corelayer to monitor background jobs and debug failures, with AI agents that root-cause job errors across your data and code stack.
## Prerequisites
* A Trigger.dev account with active projects and tasks
* Access to your Trigger.dev project settings to configure webhooks
## Step-by-Step Setup
### 1. Navigate to Integrations
In your Corelayer dashboard, go to the **Integrations** page.
### 2. Add Trigger.dev Integration
Click the **Add Integration** button and select **Trigger.dev** from the list of available integrations.
### 3. Copy the Webhook URL
Corelayer will provide a webhook URL. Copy this URL for use in the next step.
### 4. Enter Your Tasks URL
Provide the URL of your Trigger.dev tasks page (e.g., `https://cloud.trigger.dev/orgs//projects//env//tasks`). Corelayer uses this to extract your organization, project, and environment details.
### 5. Configure the Webhook in Trigger.dev
In your Trigger.dev project:
1. Go to your project settings
2. Add a new webhook with the URL provided by Corelayer
3. Copy the **webhook signing secret** generated by Trigger.dev
### 6. Enter the Webhook Secret
Paste the webhook signing secret into the Corelayer setup form and click **Save**.
## What Corelayer Can Do With Trigger.dev
Once connected, Corelayer will:
* Receive real-time webhook events when jobs fail or encounter errors
* Pull job execution context for debugging
* Correlate job failures with other integrations for root-cause analysis
* Summarize errors and suggest remediation steps
## Managing Your Integration
### Disconnecting
To disconnect your Trigger.dev integration:
1. Navigate to Settings > Integrations
2. Find your Trigger.dev integration and click **Uninstall**
3. Confirm the uninstallation
4. Remove the webhook from your Trigger.dev project settings
## Troubleshooting
### Integration Not Working?
* Verify the webhook URL is correctly configured in Trigger.dev
* Ensure the webhook signing secret matches between Trigger.dev and Corelayer
* Check that your Trigger.dev tasks URL is in the correct format
* Confirm that your Trigger.dev environment is active and running jobs
Need help? [Contact support](mailto:support@corelayer.com) for assistance with your Trigger.dev integration.
# Vercel Integration: Monitor Deployments
Source: https://docs.corelayer.com/integrations/vercel
Connect Vercel to Corelayer to monitor deployments and runtime logs, with AI agents that catch post-deploy regressions and trace them to the shipping change.
## Prerequisites
* A Vercel account with projects deployed
* Permission to create access tokens and configure log drains
## Step-by-Step Setup
### 1. Navigate to Integrations
In your Corelayer dashboard, go to the **Integrations** page.
### 2. Add Vercel Integration
Click the **Add Integration** button and select **Vercel** from the list of available integrations.
### 3. Create a Vercel Access Token
In your Vercel dashboard:
1. Go to **Settings > Tokens**
2. Click **Create** to generate a new token
3. Name the token (e.g., `Corelayer`)
4. Copy the token and paste it into the Corelayer setup form
### 4. Select Team and Projects
Once authenticated, select:
* The **Vercel team** (if applicable) that contains your projects
* The specific **projects** you want Corelayer to monitor
### 5. Configure Log Drain
Corelayer will provide you with a webhook URL for log drain configuration:
1. In your Vercel dashboard, go to **Settings > Log Drains**
2. Add a new log drain with the provided URL
3. Set the encoding to **NDJSON**
4. Add the custom headers provided by Corelayer
5. Copy the **Signature Secret** from the log drain configuration and enter it in Corelayer
### 6. Verify Connection
Click **Test Connection** to verify that Corelayer can access your Vercel account and receive logs.
## What Corelayer Can Do With Vercel
Once connected, Corelayer will:
* Monitor deployment logs for errors and anomalies
* Receive real-time log data via the configured log drain
* Correlate Vercel deployment data with other integrations for root-cause analysis
* Track project events through webhook integration
## Managing Your Integration
### Disconnecting
To disconnect your Vercel integration:
1. Navigate to Settings > Integrations
2. Find your Vercel integration and click **Uninstall**
3. Confirm the uninstallation
4. Remove the log drain from your Vercel dashboard
5. Optionally, revoke the access token in Vercel
## Troubleshooting
### Integration Not Working?
* Verify the access token is correct and has not expired
* Ensure the log drain is configured with the correct URL and encoding (NDJSON)
* Check that the signature secret matches between Vercel and Corelayer
* Confirm the selected projects are active and generating logs
Need help? [Contact support](mailto:support@corelayer.com) for assistance with your Vercel integration.
# Organization Memory: Learn From Incidents
Source: https://docs.corelayer.com/memory/overview
Corelayer retains feedback and prior incident context, then applies that memory to suppress repeat alert noise and sharpen future root-cause analysis.
## What is Organization Memory?
Corelayer keeps a per-organization memory of what it has learned about your systems. Every time you give feedback — closing an issue as a false positive, telling the assistant to ignore a class of alerts — and every time an incident is investigated, Corelayer distills the lesson into a durable memory.
That memory is then applied automatically: it stops Corelayer from re-alerting on things you've already told it to ignore, and it gives every new investigation the context of what has happened before.
Memory is scoped to your organization and isolated from every other tenant. Each memory is either **anchored to a specific resource** (a database, service, or integration) or kept **organization-wide**.
## Kinds of Memory
| Kind | What it captures | Example |
| ------------------- | ------------------------------------------------ | -------------------------------------------------------------------------------------------- |
| **Failure pattern** | A recurring failure, its root cause, and the fix | "Connection pool exhaustion on the orders DB during peak traffic — raise `max_connections`." |
| **Preference** | What you want surfaced or ignored | "Don't alert on staging timeouts." |
| **Fact** | Stable context about your systems | "The payments service runs on Postgres 14." |
| **Decision** | A standing policy | "Retry three times before escalating." |
Memory is **canonical, not a log** — when Corelayer learns the same thing again, it reinforces the existing memory and records the new evidence rather than creating a duplicate.
## How Memories Are Created
### From your feedback on issues
When you close an issue with feedback, Corelayer reads the intent:
* Feedback that means **"don't alert me about this again"** — false positive, expected / by design, won't fix, don't alert — becomes a **preference** anchored to that issue. Corelayer will suppress matching signals going forward.
* Feedback that means **"fixed / resolved / duplicate / still investigating"** is **not** treated as suppression. A recurrence after a fix is a regression worth surfacing, so Corelayer keeps watching.
Reopening an issue is treated as a correction. If a memory was created or reinforced by closing that issue, reopening it weakens or removes that memory — so a mistaken "ignore" doesn't keep hiding real problems.
### From the assistant
You can teach Corelayer directly in chat. Tell the assistant something like *"Remember that the nightly ETL job is expected to spike row counts on Mondays"* and it saves the statement as the right kind of memory (preference, fact, or decision). If the new statement contradicts something Corelayer already believes, it surfaces the conflict for you to confirm rather than silently overwriting it.
### From incidents
Corelayer consolidates resolved issues on a recurring basis, turning repeated incidents into **failure patterns** with a root cause and fix. These accumulate over time so that the next occurrence of a known failure is recognized immediately.
## How Memory Is Used
### Suppressing noise
Before Corelayer creates a new issue, it checks the signal against your **preferences** — both the exact recurrence of something you've closed before and anything semantically similar. If a standing preference clearly says to ignore it, the signal is suppressed and no issue is created. This is what keeps "I already told you about this" from happening twice.
### Sharper analysis
When Corelayer investigates a new signal, it recalls the most relevant memories for the systems involved — past failure patterns, known facts, and decisions — and feeds them into the analysis. Recall is ranked by relevance, confidence, and recency, so older or less certain memories fade in influence over time.
### Preflight: checking a change before you ship
Memory isn't only applied after a signal arrives — you can ask it about a change *before* it ships. Preflight takes a pull request's description and returns the failure modes, facts, and preferences the org has hit before for a change like that, as concrete reminders to double-check.
Run it from the CLI inside a repository, with no arguments — it derives the PR context from the current branch:
```bash theme={null}
corelayer preflight
```
It returns at most a few grounded reminders — each citing the memory behind it, its severity, and how often the org has hit it — or nothing when memory has no relevant lesson. Preflight is advisory and never blocks a push.
Agents can run it too: the [`corelayer.preflight`](/cli/mcp-server) MCP tool takes a PR description, and with the [Corelayer skill](/cli/corelayer-skill) installed, asking your assistant to "check this PR against Corelayer" routes to it. See the [CLI reference](/cli/overview#preflight) for flags and output.
## Reviewing and Managing Memory
Open **Cortex** from the sidebar to see your organization's memory. Cortex visualizes each system and the lessons attached to it, alongside organization-wide preferences, facts, and decisions.
From Cortex you can:
* **Read** what Corelayer has learned about each system
* **Edit** a memory's wording
* **Archive** a memory to stop it from influencing suppression and analysis
* **Restore** an archived memory
Memory is also reachable over the [MCP server](/cli/mcp-server) via `corelayer.search_org_memory`, so agents and MCP-compatible tools can read your organization's history for prior decisions and context.
## Related
Search organization memory from AI agents and MCP-compatible tools.
The signals that feed Corelayer's investigations and memory.
Need help? [Contact support](mailto:support@corelayer.com).
# PII Masking and Data Redaction
Source: https://docs.corelayer.com/security/pii-masking
Corelayer redacts emails, API keys, and financial data before it reaches issue summaries or AI output, so regulated teams debug without exposing customer PII.
## Overview
Corelayer uses customizable PII masking to keep sensitive customer data protected without removing the technical context engineers need for root-cause analysis.
PII is redacted before analysis so sensitive values are not exposed in issue summaries, notifications, or AI investigation output.
## Why It Matters
* Protects sensitive customer information by default
* Preserves operational visibility for faster debugging
* Supports regulated environments with stricter privacy controls
* Lets teams tune redaction based on their compliance needs
## PII Categories
Corelayer supports five masking categories:
| Category | Examples | Default |
| --------------- | -------------------------------------------------------- | --------- |
| `secrets` | API keys, tokens, credentials, private keys | Always On |
| `personal_info` | Email addresses, phone numbers, SSNs, physical addresses | On |
| `financial` | Credit card numbers, account-like financial strings | On |
| `network` | IPv4 and IPv6 addresses | Off |
| `identifiers` | UUIDs, user IDs, session IDs, coordinate-like IDs | Off |
`network` and `identifiers` are off by default to avoid over-redacting operational signals that are often required for debugging.
## How Masking Works
1. Data is ingested for issue detection and investigation.
2. PII masking rules are applied before analysis output is generated.
3. Redacted output is used in issue summaries, notifications, and investigation artifacts.
This flow reduces privacy risk while maintaining actionable debugging context.
## Configure PII Masking
1. In Corelayer, go to **Settings → Privacy**.
2. Toggle supported categories (`personal_info`, `financial`, `network`, `identifiers`).
3. Save settings.
Notes:
* `secrets` masking is always enabled and cannot be disabled.
* Settings are scoped at the organization group level.
* If a category is not explicitly configured, Corelayer uses the system default.
Need help tuning your policy? [Contact support](mailto:support@corelayer.com).
# CloudWatch
Source: https://docs.corelayer.com/webhooks/cloudwatch
Send CloudWatch alarm state changes to Corelayer through EventBridge.
Route CloudWatch alarm state changes through an EventBridge API destination to Corelayer. This preset expects the complete EventBridge event; an SNS notification uses a different payload and cannot be sent directly to this endpoint.
## Prerequisites
You need permission to add webhooks in Corelayer and deploy AWS resources in the account and Region containing your alarms. The template creates EventBridge resources, an SQS queue, and a named IAM role.
The template connects to a public HTTPS endpoint. For a private Corelayer deployment, configure [private API connectivity in EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-target-connection-create.html) before sending events.
## Setup
### 1. Create a source
In Corelayer, open **Webhooks** and click **Add Webhook**. Set **Webhook type** to **CloudWatch alarms**, enter a **Source name**, and click **Create Webhook**.
Copy the **Webhook URL**, **Webhook token**, and CloudFormation snippet. The token is shown once, so store it before clicking **Done**.
### 2. Deploy the EventBridge resources
Save the template below as `corelayer-cloudwatch.yaml`. Replace `` and `` with the values from Corelayer. If you copied the snippet from Corelayer, the URL is already filled in; you still need to replace the token placeholder.
Deploy the stack in the same account and Region as the alarms. Acknowledge the named IAM resources when creating the stack, or use `CAPABILITY_NAMED_IAM` with the CloudFormation CLI. AWS documents the [required IAM acknowledgement](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/control-access-with-iam.html).
The default rule forwards **all alarm state changes in that Region**. To select specific alarms, add a `detail.alarmName` filter to `EventPattern` before deploying. For another copy of the stack, change the explicit resource names, including the IAM role name, to avoid collisions.
```yaml theme={null}
AWSTemplateFormatVersion: "2010-09-09"
Description: Deliver CloudWatch alarm state changes to Corelayer
Resources:
CorelayerWebhookConnection:
Type: AWS::Events::Connection
Properties:
Name: corelayer-alert-webhook
AuthorizationType: API_KEY
AuthParameters:
ApiKeyAuthParameters:
ApiKeyName: Authorization
ApiKeyValue: "Bearer "
CorelayerWebhookDestination:
Type: AWS::Events::ApiDestination
Properties:
Name: corelayer-alert-webhook
ConnectionArn: !GetAtt CorelayerWebhookConnection.Arn
InvocationEndpoint:
HttpMethod: POST
InvocationRateLimitPerSecond: 10
CorelayerWebhookDeadLetterQueue:
Type: AWS::SQS::Queue
Properties:
QueueName: corelayer-alert-webhook-dlq
MessageRetentionPeriod: 1209600
CorelayerWebhookDeadLetterQueuePolicy:
Type: AWS::SQS::QueuePolicy
Properties:
Queues:
- !Ref CorelayerWebhookDeadLetterQueue
PolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: Allow
Principal:
Service: events.amazonaws.com
Action: sqs:SendMessage
Resource: !GetAtt CorelayerWebhookDeadLetterQueue.Arn
Condition:
ArnEquals:
aws:SourceArn: !GetAtt CorelayerAlarmStateChangeRule.Arn
CorelayerWebhookRuleRole:
Type: AWS::IAM::Role
Properties:
RoleName: corelayer-alert-webhook-rule-role
AssumeRolePolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: Allow
Principal:
Service: events.amazonaws.com
Action: sts:AssumeRole
Policies:
- PolicyName: invoke-corelayer-webhook
PolicyDocument:
Version: "2012-10-17"
Statement:
- Effect: Allow
Action: events:InvokeApiDestination
Resource: !GetAtt CorelayerWebhookDestination.Arn
CorelayerAlarmStateChangeRule:
Type: AWS::Events::Rule
Properties:
Name: corelayer-alarm-state-change
EventPattern:
source:
- aws.cloudwatch
detail-type:
- "CloudWatch Alarm State Change"
Targets:
- Id: corelayer-webhook
Arn: !GetAtt CorelayerWebhookDestination.Arn
RoleArn: !GetAtt CorelayerWebhookRuleRole.Arn
RetryPolicy:
MaximumRetryAttempts: 5
MaximumEventAgeInSeconds: 3600
DeadLetterConfig:
Arn: !GetAtt CorelayerWebhookDeadLetterQueue.Arn
```
The connection sends `Authorization: Bearer `. The rule forwards the full event without an input transformer. Its role permits `events:InvokeApiDestination` on this destination, and the queue policy permits this rule to send failed deliveries to the dead-letter queue.
Creating the first API destination connection may also require permission to create the EventBridge service-linked role. EventBridge uses that role to manage the connection secret in Secrets Manager. See [API destination permissions](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-api-destinations.html).
### 3. Check an alarm transition
When an alarm next changes to `ALARM`, check the EventBridge rule's monitoring metrics and look for the resulting investigation in Corelayer. A successful API call confirms delivery, not completion of the investigation.
If delivery fails, inspect the dead-letter queue and its message error attributes. The template allows up to five retries within one hour and retains queued failures for 14 days. AWS explains [dead-letter queue errors and permissions](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-rule-dlq.html).
## How alerts are handled
`ALARM` starts an investigation. `OK` records a resolution without closing the Corelayer issue. Other states, including `INSUFFICIENT_DATA`, are recorded without investigation.
Keep the complete [CloudWatch alarm event](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch-and-eventbridge.html). Corelayer reads the alarm name, state, reason, and available metric details from its `detail` object.
See [Manage sources](/webhooks/overview#manage-sources) to change or remove this source.
## Troubleshooting
* **The rule does not match:** Check its AWS account, Region, event pattern, and whether the alarm changed state after the rule was created.
* **Authentication fails:** Check the connection's API key name is `Authorization` and its value contains `Bearer ` followed by the Corelayer token.
* **The target cannot be invoked:** Check the destination URL and the rule role's `events:InvokeApiDestination` permission. For private endpoints, check the connection's network configuration.
* **No investigation starts:** Confirm the event has `detail.state.value` set to `ALARM` and was delivered without an input transformer or SNS envelope.
Need help? [Contact support](mailto:support@corelayer.com).
# Custom alerts
Source: https://docs.corelayer.com/webhooks/custom
Send JSON alerts to Corelayer using a webhook URL and bearer token.
Send alerts from a monitoring tool that supports the JSON format below. For incident.io, CloudWatch, Datadog, or Honeycomb, start with the [matching webhook type](/webhooks/overview#add-a-webhook).
## Prerequisites
You need permission to add webhooks in Corelayer and a tool that can POST JSON to the webhook URL.
## Setup
### 1. Create a source
Open **Webhooks** and click **Add Webhook**. Set **Webhook type** to **Custom Webhook**, enter a **Source name** such as `Checkout alerts`, and click **Create Webhook**.
Copy the **Webhook URL**, **Webhook token**, and **Example request**. The token is shown once, so store it before clicking **Done**.
### 2. Configure your alert sender
Set your monitoring tool to POST the [JSON alert payload](#alert-payload) to the webhook URL with these headers:
```text theme={null}
Authorization: Bearer
Content-Type: application/json
```
The URL must be reachable from the sender. For customer-hosted Corelayer, a private URL works when the sender is on the same network. Cloud-hosted senders need access from their own network.
### 3. Send an example alert
Run the example `curl` request from a machine that can reach the endpoint. Use the current timestamp when sending a new example.
This sends a real alert and can start an investigation. A `202` response means the request was accepted; read its `status` field to see whether it was queued, ignored as a duplicate, or skipped. For a queued alert, check Corelayer for the resulting investigation.
## Alert payload
Send one alert per request. Use the alert's actual timestamp for `time`:
```json theme={null}
{
"id": "checkout-500-rate",
"action": "trigger",
"time": "2026-09-09T12:00:00Z",
"name": "Checkout API 500 rate is elevated",
"message": "5xx rate crossed 5% for checkout-api",
"severity": "high",
"source": "checkout-monitor",
"fingerprint": "checkout-api:5xx-rate:prod",
"labels": {
"service": "checkout-api",
"environment": "prod"
}
}
```
### Required fields
| Field | Description |
| --------- | ------------------------------------------------------------------------------- |
| `id` | Alert identifier from your monitoring tool |
| `action` | `trigger`, `resolve`, or `acknowledge` |
| `time` | Alert timestamp as a valid date string; use RFC 3339, such as the example above |
| `name` | Short alert name |
| `message` | Alert message or summary |
### Optional fields
| Field | Description |
| ------------- | ------------------------------------------------------------------------------- |
| `description` | Longer alert details |
| `severity` | `critical`, `high`, `medium`, `low`, or `info`. Defaults to `info` when omitted |
| `source` | Name of the monitoring tool |
| `sourceUrl` | URL of the alert in the monitoring tool |
| `fingerprint` | Stable key used to identify repeated alerts |
| `labels` | Key-value labels such as service, environment, or region |
### Map your payload
If your tool supports a custom payload template, map its fields to this format. Set `action` to `trigger` when the alert fires and `resolve` when it recovers. Use a stable `fingerprint` for repeated notifications of the same alert.
Omit optional fields that have no value. For example, `severity: ""` is invalid; omit `severity` to use `info`.
## How alerts are handled
* `trigger` sends the alert for investigation.
* Repeated triggers with the same fingerprint are accepted but ignored during the deduplication window.
* `resolve` and `acknowledge` are recorded but do not automatically close Corelayer issues.
See [Manage sources](/webhooks/overview#manage-sources) to change or remove this source.
## Troubleshooting
### The sender cannot reach the endpoint
Check the URL and network access from the system sending alerts. For a private deployment, test from that network rather than your laptop.
### The endpoint returns an error
| Response | Check |
| -------- | -------------------------------------------------------------------------------------------------------- |
| `400` | Read the response detail. Check the JSON, required fields, and allowed `action` and `severity` values |
| `401` | Check the bearer token and `Authorization` header. If the token is lost, rotate it and update the sender |
| `403` | The webhook is disabled |
| `404` | Check the exact URL and confirm the webhook still exists |
### No investigation starts
Read the response's `status`. A duplicate trigger is ignored, and resolution or acknowledgement events are only recorded. If it reports `skipped_onboarding`, complete your organization's onboarding and send a new alert.
Need help? [Contact support](mailto:support@corelayer.com).
# Datadog
Source: https://docs.corelayer.com/webhooks/datadog
Send Datadog monitor alerts to Corelayer for investigation.
Configure a Datadog webhook to send monitor notifications to Corelayer. The preset uses the monitor's name, query, scope, and state transition to describe the alert.
To give investigations access to Datadog logs and metrics, also connect the [Datadog integration](/integrations/datadog).
## Prerequisites
You need permission to add webhooks in Corelayer, configure Datadog's Webhooks integration, and edit the monitors you want to connect.
## Setup
### 1. Create a source
In Corelayer, open **Webhooks** and click **Add Webhook**. Set **Webhook type** to **Datadog monitors**, enter a **Source name**, and click **Create Webhook**.
Copy the **Webhook URL**, **Webhook token**, and payload template. The token is shown once, so store it before clicking **Done**.
### 2. Configure Datadog
Open Datadog's **Webhooks** integration tile. Add a webhook named `corelayer` and set its URL to the Corelayer webhook URL.
Create a custom variable named `CORELAYER_WEBHOOK_TOKEN` with the Corelayer token as its value, and select **hide from view**. In the webhook's custom headers, enter:
```json theme={null}
{
"Authorization": "Bearer $CORELAYER_WEBHOOK_TOKEN",
"Content-Type": "application/json"
}
```
Datadog supports [custom variables in headers](https://docs.datadoghq.com/integrations/webhooks/#custom-variables), so you can update the token without editing the header format.
Set **Payload** to this template and leave **Encode as form** unchecked:
```json theme={null}
{
"id": "$ALERT_ID",
"title": "$ALERT_TITLE",
"metric": "$ALERT_METRIC",
"query": "$ALERT_QUERY",
"scope": "$ALERT_SCOPE",
"transition": "$ALERT_TRANSITION",
"date": "$DATE_POSIX",
"url": "$LINK"
}
```
Keep the variable names in the template; Datadog fills them when it sends a notification. `$DATE_POSIX` supplies the event time in seconds. Save the webhook.
### 3. Add it to a monitor
Edit the monitor's notification message and add `@webhook-corelayer`. If you chose a different webhook name, use `@webhook-`. Save the monitor. Datadog's [webhook setup guide](https://docs.datadoghq.com/integrations/webhooks/#usage) explains the notification syntax.
When the monitor sends a **Triggered** or **Re-Triggered** notification, look for the resulting investigation in Corelayer.
## How alerts are handled
`Triggered` and `Re-Triggered` start investigations. `Recovered` records a resolution without closing the Corelayer issue. Other transitions, including `Warn`, `No Data`, and `Renotify`, are recorded without investigation.
Repeated notifications may be suppressed as duplicates. An accepted webhook request does not mean an investigation has finished.
See [Manage sources](/webhooks/overview#manage-sources) to change or remove this source.
## Troubleshooting
* **No notification arrives:** Check that the monitor includes the correct `@webhook-` mention and that the monitor was saved.
* **`401` response:** Check the custom variable's value and the `Authorization` header. The value after `Bearer` must be the Corelayer webhook token.
* **Missing alert details:** Use the full payload template above and the **Datadog monitors** source type. Datadog's default payload has a different shape.
* **No investigation starts:** Check `transition` in the payload. Recovery, warning, no-data, and renotify notifications do not start investigations.
Need help? [Contact support](mailto:support@corelayer.com).
# Honeycomb
Source: https://docs.corelayer.com/webhooks/honeycomb
Send Honeycomb trigger alerts to Corelayer for investigation.
Connect Honeycomb triggers to Corelayer using a webhook recipient and a trigger payload template. This preset supports trigger alerts; SLO burn alerts are not supported.
## Prerequisites
You need permission to add webhooks in Corelayer and manage integrations and trigger recipients in your Honeycomb team.
## Setup
### 1. Create a source
In Corelayer, open **Webhooks** and click **Add Webhook**. Set **Webhook type** to **Honeycomb triggers**, enter a **Source name**, and click **Create Webhook**.
Copy the **Webhook URL**, **Webhook token**, and trigger payload template. The token is shown once, so store it before clicking **Done**.
### 2. Configure Honeycomb
In Honeycomb, open **Team Settings → Integrations**. Under **Trigger and SLO Recipients**, choose **Add Integration** and select **Webhook** as the provider.
Give the recipient a name, paste the Corelayer URL into **Webhook URL**, and paste the token into **Shared Secret**. Honeycomb sends this secret in the `X-Honeycomb-Webhook-Token` header. Use the token alone, without a `Bearer` prefix.
In the **Payload** tab, enable **Triggers** and paste this template, also provided by Corelayer:
```json theme={null}
{
"alert_type": "trigger",
"id": "{{ .ID }}",
"instance_id": "{{ .Alert.InstanceID }}",
"name": "{{ .Name }}",
"description": "{{ .Description }}",
"status": "{{ .Alert.Status }}",
"summary": "{{ .Alert.Summary }}",
"timestamp": "{{ .Alert.Timestamp }}",
"url": "{{ .URL }}",
"result_url": "{{ .Result.URL }}",
"environment": "{{ .Environment }}",
"datasets": {{ toJson .Datasets }},
"operator": "{{ .Operator }}",
"threshold": "{{ .Threshold }}",
"query_time_range": "{{ .Query.TimeRange }}",
"result_groups": {{ toJson .Result.Groups }},
"groups_triggered": {{ toJson .Result.GroupsTriggered }},
"is_test": "{{ .Alert.IsTest }}"
}
```
Click **Add** to save the recipient. Honeycomb's [webhook guide](https://docs.honeycomb.io/notify/webhooks) covers these settings.
### 3. Add the recipient to a trigger
Open a trigger in Honeycomb. Under **Recipients**, click **Add Recipient**, select the webhook, and click **Add**. Save the trigger. Repeat for each trigger you want to send to Corelayer.
When a trigger fires, look for the resulting investigation in Corelayer. Honeycomb test notifications are recorded without starting an investigation.
## How alerts are handled
`TRIGGERED` starts an investigation. `OK` records a resolution without closing the Corelayer issue. Other statuses and notifications marked `is_test` are recorded without investigation.
The payload includes the trigger name, summary, environment, datasets, threshold, and result groups. Corelayer also preserves links to the trigger and query result when available.
See [Manage sources](/webhooks/overview#manage-sources) to change or remove this source.
## Troubleshooting
* **No alert arrives:** Check that the webhook is a recipient on the trigger and that the trigger was saved.
* **`401` response:** Check the recipient's **Shared Secret** against the Corelayer token.
* **`400` response:** Check that the source uses **Honeycomb triggers** and that the **Triggers** payload matches the template. Keep `toJson` around the array fields; Honeycomb documents this in its [template variables reference](https://docs.honeycomb.io/notify/webhooks/variables).
* **No investigation starts:** Check the alert status and `is_test` value. A test or recovery notification does not start an investigation.
Need help? [Contact support](mailto:support@corelayer.com).
# incident.io
Source: https://docs.corelayer.com/webhooks/incidentio
Send incident.io alerts and declared incidents to Corelayer for investigation.
You'll copy a URL from Corelayer into incident.io, then bring the endpoint's signing secret back to Corelayer.
## Prerequisites
You need permission to add webhooks in Corelayer and configure webhooks in incident.io.
## Setup
### 1. Get the URL
In Corelayer, open **Webhooks** and click **Add Webhook**. Set **Webhook type** to **incident.io**, enter a **Source name** such as `Production incidents`, and click **Next**.
Copy the **Webhook URL**. Keep the form open while you configure incident.io in another tab.
### 2. Add the endpoint in incident.io
In incident.io, go to **Settings → Webhooks**, click **Add endpoint**, and paste the Corelayer URL.
Subscribe to the events you want Corelayer to receive:
| Event type | What Corelayer does |
| -------------------------------------- | ---------------------------------- |
| `public_alert.alert_created_v1` | Investigates the alert |
| `private_alert.alert_created_v1` | Investigates the alert |
| `public_alert.alert_resolved_v1` | Records the resolution event |
| `private_alert.alert_resolved_v1` | Records the resolution event |
| `public_incident.incident_created_v2` | Investigates the declared incident |
| `private_incident.incident_created_v2` | Investigates the declared incident |
Save the endpoint, then copy its **Signing Secret**.
If you're updating an endpoint that only sends alerts, add the incident-created events to receive declared incidents. Existing subscriptions are not updated automatically.
### 3. Finish setup
Return to Corelayer. Paste the signing secret (`whsec_...`) into **Webhook signing secret** and click **Create Webhook**.
After a subscribed event occurs, open the endpoint's delivery attempts in incident.io and check the response from Corelayer. A successful delivery confirms receipt; it does not mean the investigation has finished.
## After delivery
Created alerts and declared incidents are sent for investigation. Alert resolutions are recorded but do not automatically close Corelayer issues.
Other event types, including incident updates, are accepted and ignored. Updates do not continue an existing investigation, and Corelayer does not write changes back to incident.io.
### Declared incidents
Investigations use the incident reference and name, for example `INC-123: Checkout returning 500s`, with the summary as the description and a link back to incident.io.
Severity and status are recorded as labels because their definitions vary between incident.io workspaces. Incident type, mode, visibility, Slack channel, role assignments, and custom fields are also included as labels.
Test incidents are investigated too, with the label `incidentio.mode: test`.
See [Manage sources](/webhooks/overview#manage-sources) to change or remove this source.
## Troubleshooting
### No delivery appears in incident.io
Check the endpoint's event subscriptions. Alert subscriptions do not include declared incidents; those need the public or private `incident_created_v2` event from the table above.
### A delivery fails
Open the failed delivery in incident.io and inspect the HTTP response:
* `401`: Check that the signing secret matches this endpoint's secret.
* `403`: The webhook is disabled.
* `404`: Check that incident.io has the exact URL Corelayer issued and that the webhook still exists.
### No investigation starts
Check the event type first. Resolution events are recorded, and unsupported event types are ignored. Repeated alerts can also be suppressed as duplicates.
Your Corelayer organization must finish onboarding before alerts can be investigated. If the response reports `skipped_onboarding`, complete onboarding and send a new alert.
Need help? [Contact support](mailto:support@corelayer.com).
# Overview
Source: https://docs.corelayer.com/webhooks/overview
Receive alerts from monitoring tools and incident.io.
Send alerts to Corelayer for investigation. Each webhook has its own URL and authentication settings.
## Add a webhook
Open **Webhooks** from the sidebar and click **Add Webhook**. Choose a **Webhook type**:
* [incident.io](/webhooks/incidentio): Send alerts and declared incidents using an incident.io signing secret.
* [Honeycomb](/webhooks/honeycomb): Send trigger alerts using a webhook recipient and shared secret.
* [CloudWatch](/webhooks/cloudwatch): Forward alarm state changes through an EventBridge API destination.
* [Datadog](/webhooks/datadog): Send monitor notifications using a webhook payload template.
* [Custom alerts](/webhooks/custom): Send alerts in Corelayer's JSON format using a bearer token.
Enter a **Source name**, such as `Production incidents`, so you can recognize the webhook in the list.
## Manage sources
Open **Webhooks** and expand a source to view its URL and authentication details.
### Enable or disable
Use the source's **Enabled** switch. The change takes effect as soon as it succeeds.
Disabling keeps the webhook's configuration. Incoming requests receive `403` until you enable it again.
### Delete a source
Select the checkbox beside each source you want to delete, then click **Delete selected**. Review the source names in the confirmation and choose **Delete webhook** or **Delete webhooks**. Choose **Cancel** to keep them.
Also remove the webhook from the system sending alerts so it stops calling the deleted URL.
### Rotate a token
For a webhook that uses a bearer token, expand the source and click **Rotate token** beside its masked token. Confirm the rotation, then copy the new token from the completion dialog before closing it. The new token is shown once.
Update your alert sender with the new token. The old token stops working immediately after rotation.
incident.io webhooks use a signing secret from incident.io instead of a Corelayer bearer token.
Need help? [Contact support](mailto:support@corelayer.com).