Limits
This page covers the product limits that apply at every plan — the in-form caps, retention windows, and validation rules. For per-plan endpoint and channel counts (and how to lift them), see Pricing.
Per-plan caps
Endpoint and notification channel counts are capped per plan and enforced by Postgres triggers. The Add button disables at the cap; over-cap inserts return PT403. See Pricing for the per-plan numbers.
The demo tier (the public showcase account) is read-only at three layers — see Demo tier read-only enforcement below.
In-form caps
These apply at every tier — they’re product limits rather than billing levers:
| Limit | Value | Enforced where |
|---|---|---|
| Minimum check interval | 60 seconds | DB CHECK constraint + form preset chips. |
| Assertions per endpoint | 10 | Add / Settings forms. |
| Endpoint description length | 500 characters | Form input slice. |
| Port (TCP checks) | 1–65535 | Form validation. |
| Password (sign-up / reset) | 8 characters | Auth server actions. |
| Webhook body template size | 16 KB rendered | Webhook channel send path. |
A few things you might expect to be capped, but aren’t today:
- No max length on endpoint name, channel name, or display name.
- No cap on the number of custom headers on an endpoint or webhook channel.
- No cap on the number of recipients on an email channel.
- No request-rate cap on dashboard / API queries.
Retention windows
How long each kind of data lives. See Incidents → Retention for the same table with more context, and the heads-up in Settings → Retention about a known UI/cron mismatch.
| Data | Retention |
|---|---|
| Incidents | Indefinite (no scheduled cleanup) |
| Daily summaries | Indefinite (no scheduled cleanup) |
| Hourly summaries | 30 days |
| Notification log | 90 days |
| Check rows | 48 hours |
Error code: PT403
The only custom Postgres error code WatchDeck raises. It comes from the quota triggers (enforce_endpoint_quota, enforce_channel_quota) on BEFORE INSERT of mx_endpoints / mx_notification_channels.
When the form catches a PT403, it surfaces a friendly message inline naming your plan, the cap, and your current count. If you ever hit one through a script or future API call, the raw message contains the same fields so you can format your own.
Tier visibility in the UI
Plan tier surfaces in three small places:
- The Quota banner on
/endpointsand/notificationsshows your current count against your cap. - A small tier note on the Retention panel under Settings.
- The Demo banner on every page when you’re signed into the demo account.
There’s no dedicated “Plan & usage” page or usage progress meter in Settings — see Pricing for the canonical plan information.
Demo tier read-only enforcement
Demo accounts are blocked from writes at three layers, in this order:
- Postgres RLS. Every
INSERT/UPDATE/DELETEpolicy on user-data tables wraps aWITH CHECK (NOT is_readonly_user(uid))so the database itself rejects writes. - Server actions. Privileged actions (those that bypass RLS via the service-role client, e.g.
deleteAccount) callassertNotReadonlyand refuse early with a typed error. - UI. Action buttons are wrapped in
<DemoGate>, which disables the underlying button and tooltips the user explaining demo mode.
The triple coverage means demo accounts can’t write through any path the product ships, including future API access.
Asking for higher caps
See Pricing for plan availability and how to lift your caps.