Watches

A Watch is a check that runs on a schedule and only speaks up when something is off. It is silent by default. You don’t open a Watch; it comes to you.

The whole point is to replace the ritual of “logging in every morning to see if everything is fine.” You set up a Watch, you forget about it, and it taps you on the shoulder when the number moves.

Anatomy of a Watch

Four parts:

• Query — a SQL / Python / fetch that produces a single value or small result set each run.
• Condition — a rule about that value. > 0.03, < -15, different from yesterday, missing.
• Schedule — how often to check. Every 5 minutes, Every hour, Every day at 08:00.
• Notification — where to send the alert. Email, Slack, webhook, or multiple.

Optionally:

• Quiet hours — suppress during configured windows.
• Debounce — require the condition to be true for N minutes before firing.
• Acknowledge / Snooze — user actions that pause further alerts for a period.

Creating a Watch

Easiest path: ask the Agent.

> Ping me if refund rate goes above 3% in the last 24 hours.

The Agent:

1. Writes the query (refunds / orders for the last 24h).
2. Picks a condition (> 0.03).
3. Picks a schedule (hourly — the fastest that makes sense given rolling 24h data).
4. Asks where to notify.
5. Creates the Watch.

You can also create from an Agent answer’s Keep bar — ＋ Watch — or build manually in Sidebar → Watches → + New.

Conditions

Watches support these condition types:

Type	Example	Notes
Threshold	refund_rate > 0.03	Most common.
Relative	today vs 7-day average, > 20% off	Useful for seasonal data.
Missing	no rows in last hour	Useful for data pipelines.
Trend	3 consecutive days of decline	Useful for slow burns.
Anomaly	outside 95% confidence band	Uses Python’s detection. Good when you don’t know the threshold.

The Agent picks one based on your phrasing. You can switch types in the Watch settings.

Debouncing

Alerts are loudest when they’re rare. Default behavior:

• Fire once when the condition becomes true.
• Stay silent while it remains true.
• Fire resolved when it returns to normal.

You can add a “true for at least N minutes” requirement for flickery data — common on IoT sensors that oscillate around a threshold.

Notification channels

Per Watch, multiple channels:

• Email — the default. Goes to your account email unless you override.
• Slack — pick a channel from the dropdown (after workspace admin connects the Slack integration).
• Webhook — for pagerduty, opsgenie, custom.
• SMS — Max plan, via Twilio.
• In-app — appears in the Tablize inbox with a badge.

Each channel can have its own severity filter — e.g., route “warning” to email, “critical” to Slack + SMS.

Quiet hours

A Watch can be scoped to a time window:

• Always — default.
• Office hours — your configured work hours.
• Overnight — e.g., 20:00 to 07:00.
• Custom — any cron-style expression.

Outside the window, checks still run but alerts don’t fire. If the condition is still true when you come back online, you get a “was firing during quiet hours” summary.

Acknowledging and snoozing

When an alert fires:

• Acknowledge — tells Tablize you’ve seen it. Suppresses further alerts on the same condition until it resolves and re-fires.
• Snooze for N hours — pauses checks entirely for that window.
• Investigate — drops you into a new chat session with the alert as context; the Agent pre-loads the data that triggered it.

Unacknowledged alerts escalate on a schedule (optional): re-notify after 15 minutes, then hourly, then stop.

Combining with Scripts

A Watch’s query can be a Script. This is how you build complex, multi-step checks:

• Script computes a derived metric.
• Watch compares the metric to a threshold.

Useful when the metric involves joins across tables, multi-step Python, or LLM-based classification (e.g., “alert me if sentiment in support tickets drops below X”).

IoT Watches

Watches are the most common asset on IoT data. The Agent understands Space / Asset / Point from plain English:

> Alert me if any freezer in Cold Room 2 reads above -15°C for more than 5 minutes overnight.

The Agent:

1. Resolves “any freezer in Cold Room 2” to the right asset subset.
2. Writes a check against the temperature point.
3. Adds a 5-minute debounce.
4. Adds quiet hours (overnight = 20:00 to 07:00).
5. Notifies on Slack.

See IoT, MQTT & cameras for more on the Asset graph.

Checking on Watches

Sidebar → Watches shows:

• Every Watch, active or paused.
• Last fired-at and current state (ok / warning / critical / paused).
• Next scheduled check.
• Recent alert history.

Click any Watch to see its query, condition, recent firings, and edit anything.

Watches vs Watch history

Two different things:

• Watch — the rule itself. Lives in the Watches section of the Sidebar.
• Watch history — every time a Watch ran, what value it saw, whether it fired. Stored for 90 days.

You can query Watch history via SQL (platform.watch_runs) — useful for “how often did this alert fire last month?” meta-analyses.

Common gotchas

• Watch fires constantly right after creation. Your threshold is too tight for normal volatility. Add a debounce or relative-delta condition.
• Watch doesn’t fire when you expect. Check that the query returns what you think. In the Watch page, click Test run — it executes the query and shows the raw value.
• No notifications received. Check notification settings — email goes to spam sometimes; Slack requires the app installed. The Watch page shows delivery status per channel.
• Watches slow the database down. Too many frequent Watches on large tables can compete with your app queries. Use longer intervals, or route to a read replica.

Next steps

• IoT, MQTT & cameras — sensor data is the most common Watch target.
• Scripts — build multi-step logic once, Watch on its output.
• Dashboards — sometimes you want to see the data, not just be paged about it.