Skip to main content

​
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:
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: 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 for assistance with table monitoring.