> ## Documentation Index
> Fetch the complete documentation index at: https://docs.corelayer.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Database Table Monitoring and Alerts

> 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.


## Related topics

- [Corelayer Changelog: April 2026 Release](/changelog/april-2026.md)
- [Anomaly Detection for Data Pipelines](/anomalies/overview.md)
- [Custom alerts](/webhooks/custom.md)