Feature: Support ChecklyHQ Importer

[aggmoulik]

Summary

Adds a ChecklyHQ importer so users can migrate their Checkly monitors and status page into OpenStatus in one step, from the dashboard import flow.

What it does

The importer talks to the Checkly public API (v1) using an API key + account ID and maps Checkly resources onto their OpenStatus equivalents:

Checkly	OpenStatus
Checks (API / URL types)	Monitors
Status Page	Status Page
Cards	Component Groups
Services	Components
Incidents	Status Reports
Maintenance Windows	Maintenances

Non-HTTP check types (browser, TCP, …) and checks without a target URL are reported as skipped with a reason instead of failing the whole import.

Changes

• New provider under packages/importers/src/providers/checkly/ — client, mapper, api-types, provider, each with unit tests.
• Handles both Checkly pagination styles (cursor envelope { entries, nextId } and bare-array page) and sends both auth headers (Authorization: Bearer, X-Checkly-Account).
• Registered the provider and a Checkly icon in @openstatus/icons.
• Dashboard import form gains a Checkly option (account ID + API key fields).
• Service-layer wiring in packages/services/src/import (preview, run, provider, schemas).
• Docs: new "Migrate from Checkly" guide + updates to the import how-to.

Config

• Checkly API key — Checkly → User Settings → API keys
• Checkly account ID — Checkly → Account Settings → General

Testing

• Unit tests for the client (cursor + page pagination, auth headers, API-error handling), mapper, and provider.
• Verified end-to-end against a live Checkly account — checks, status page, cards, services, incidents, and maintenance windows all import. Fixed a schema mismatch surfaced by live data (Checkly returns a numeric maintenance-window id; it's now coerced to a string to match the import contract, with a regression test).

[vercel]

@aggmoulik is attempting to deploy a commit to the OpenStatus Team on Vercel.

A member of the Team first needs to authorize it.

[cubic-dev-ai]

All reported issues were addressed across 24 files

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[aggmoulik]

@claude Review

[mxkaske]

@claude review

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
openstatus-dashboard	Ready	Preview, Comment	Jul 15, 2026 6:51pm
openstatus-status-page	Ready	Preview, Comment	Jul 15, 2026 6:51pm
openstatus-web	Ready	Preview, Comment	Jul 15, 2026 6:51pm

[claude]

Claude finished @mxkaske's task in 3m 5s —— View job

---

Claude finished @mxkaske's task

• Gather context (PR diff, review comments, CLAUDE.md conventions)
• Review new Checkly importer provider (client, mapper, provider, api-types)
• Review service-layer wiring (packages/services/src/import)
• Review dashboard form changes
• Verify prior cubic-dev-ai review findings were actually addressed in c84a2f3
• Post final review

Review

Overall this is solid, well-tested work — good pagination handling, sensible skip-with-reason UX for unsupported check types, and the mapper unit tests are thorough. Two of the three prior cubic-dev-ai findings check out as genuinely fixed. One does not, and I found one related structural issue worth considering.

🔴 The P1 getIncidents finding is marked "Addressed" but the code is unchanged

c84a2f3 ("Fixed after code review") only touched form-import.tsx, checkly.tsx, and mapper.ts. client.ts and provider.ts were not modified — getIncidents() still calls cursorAll("/v1/status-pages/incidents", ...) at client.ts:106-107, and provider.ts:169 still calls it unconditionally whenever a status page is found. The "✅ Addressed" checkmark on that thread appears to be inaccurate.

That said, the PR description says this was verified end-to-end against a live Checkly account and incidents did import — which argues the endpoint may in fact be valid (a real 404 would throw regardless of whether the account has zero incidents, since request() checks response.ok before parsing). So the two signals contradict each other: the bot says the collection path is unsupported, the live test claims it worked. I can't verify against Checkly's actual API spec from here — worth double-checking against Checkly's OpenAPI docs before merging, since if the bot is right, imports with a status page fail entirely (see next point).

Investigate & fix if needed →

🟡 A single failed fetch aborts the entire import with zero phases written

provider.run() (provider.ts) fetches checks, status pages, incidents, and maintenance windows sequentially with no try/catch, all before returning the ImportSummary. runImport's own docstring (run.ts:21-29) describes the import model as "phase-level recovery — a failing phase aborts subsequent phases but preserves earlier phases' writes" — but that recovery only applies to the write loop. If client.getIncidents() (or any other provider fetch) throws, the exception propagates out of provider.run() unhandled, so previewImport/runImport never even get a summary back — monitors and the status page that were already fetched successfully are lost too, not just skipped. This isn't unique to Checkly, but the new getIncidents call is a new failure point worth guarding, e.g. wrapping that fetch so a failure there degrades to a skipped/partial incidents phase rather than killing the whole run.

✅ Verified fixed from the prior review

• mapper.ts active field — now correctly active: check.activated (not && !check.muted), with a comment explaining muted checks still run. Confirmed in c84a2f3.
• form-import.tsx blank Account ID — client-side validation now sets a field error via form.setError("checklyAccountId", ...) plus <FormMessage /> before the preview call. Confirmed in c84a2f3.
• mapper.ts mapFrequency supported array — now derived via Object.keys(FREQUENCY_MAP).map(Number) instead of a separately hardcoded array. Confirmed in c84a2f3.

Minor / non-blocking observations

• packages/importers/src/providers/checkly/mapper.ts:117-119 — the active: check.activated comment is good; no action needed, just noting it reads correctly now.
• Test coverage is good (client pagination/auth/error cases, mapper unit tests, provider phase-composition tests) but all fixture-based, so none of it would have caught a real 404 on /v1/status-pages/incidents — consistent with why this slipped through.

I wasn't able to run the test suite or linter in this environment (no network access to fetch dependencies/turso dev), so this review is based on static reading of the diff only.
(branch)