CamplaxUptime monitoring
Every live project gets a Production monitor — plus custom HTTP checks, confirmed incidents, email alerts and a public status page.
You do not set up monitoring on Camplax — it is already running. The moment a project goes live, a monitor named Production starts checking https://<slug>.camplax.app/ every 15 minutes. Custom monitors add paths and custom domains on top, up to 5 monitors per project.
What a monitor checks
Each monitor is an HTTPS request against one of your project's hosts — the <slug>.camplax.app URL or any custom domain with an active certificate:
| Setting | Default | Limits |
|---|---|---|
name | — | 1–80 characters |
path | / | a path on the monitor's host |
method | GET | GET or HEAD |
expectedStatusMin – expectedStatusMax | 200–299 | any range inside 100–599 |
assertion | none | contains or not_contains text (≤200 chars); needs GET |
timeoutMs | 10000 | 1,000–10,000 ms |
followRedirects | on | up to 3 redirects, and only to your own project hosts |
enabled | on | pause a monitor instead of deleting it |
Two deliberate constraints: checks only ever target your hosts (a monitor cannot be aimed at an arbitrary URL), and the request is pinned to the Camplax edge rather than your DNS — so a hijacked nameserver cannot feed the monitor a forged answer. Response bodies are read only up to 256 KB, just enough to run the assertion.
The automatic Production monitor is special: it cannot be deleted (pause it instead) and it cannot be repointed — it must keep watching the project's production URL. New monitors get a 5-minute warm-up so deploy noise does not open incidents.
Incidents and alerts
A failed check does not immediately page you. The platform re-checks 20 seconds later and only opens an incident when the second check fails too — one bad packet is not an outage. Recovery works the same way: a success while down is confirmed once before the incident resolves.
When an incident opens or resolves, emails go to the project's alert recipients — any owner or member seat with a verified email. The project owner is added by default; edit the list under Uptime → Alerts. The same list receives error alerts.
SSL expiry warnings ride the same rail: once a day the platform reads the certificate on each active custom domain and emails when expiry is 30, 14, 7 or 1 day out.
The status page
Each project can publish a status page without any code. Enable it under Uptime → Status page, give it a title, and pick which monitors are public:
- Page:
https://camplax.dev/status/<slug>— status banner, per-monitor 90-day uptime, recent incidents. - JSON:
https://camplax.dev/v1/status/<slug>— the same data for a status badge in your own UI. - Embeds: a badge or card for your own site:
<script src="https://camplax.dev/status.js" data-project="<slug>" data-layout="badge" async></script>The public page only ever shows what you selected — monitor names, up/down status and incident summaries like "Service disruption", never internal error text.
The API surface
All of the above is also scriptable — every route takes a console session, and nothing here is reachable with a project API key.
| Endpoint | What it does |
|---|---|
GET /v1/projects/:slug/uptime | Monitors, recent incidents, domains, recipients, status-page config |
POST /v1/projects/:slug/uptime/monitors | Create a monitor (409 monitor_limit past 5) |
PATCH /v1/projects/:slug/uptime/monitors/:id | Edit a monitor |
DELETE /v1/projects/:slug/uptime/monitors/:id | Delete (the automatic monitor refuses) |
POST /v1/projects/:slug/uptime/monitors/:id/test | Run one check right now |
GET /v1/projects/:slug/uptime/monitors/:id/series?range=24h|7d|30d|90d | Latency/uptime series for charts |
GET /v1/projects/:slug/uptime/incidents | Incident history (resolved entries age out after a year) |
PATCH /v1/projects/:slug/uptime/recipients | Choose who gets alert email (owner only) |
PATCH /v1/projects/:slug/uptime/status-page | Enable, title and select public monitors (owner only) |
GET /v1/status/:slug | Public JSON for the status page — no sign-in |