Importer Capability Matrix

If you are moving to HowlOps from another monitoring or on-call tool, there are two separate paths in, and they cover different ground. This page is a single reference for what the provider importer actually brings over for each source it supports, and what it deliberately leaves for you to redo by hand. For the full step-by-step flow of any one provider, follow its own tutorial linked below; this page only summarizes the result.

Two ways to bring in existing setup

Provider import (Settings → Import) connects to a competitor account with a read-only API key, fetches its configuration, shows you a preview labelled Exact, Imports with changes (lossy), or Unsupported for every item, and creates only what you select. It is the only path that can migrate on-call structure (teams, schedules, escalation policies) in addition to monitors, and it is supported for six sources: UptimeRobot, Better Stack, Pingdom, PagerDuty, Opsgenie, and Jira Service Management (JSM) Operations.

Bulk import (Monitors → Bulk import) creates up to 200 monitors at once from a CSV or JSON file you prepare yourself. It does not talk to any other vendor's API, so it works as a fallback for any source, including ones with no provider importer, but it only ever creates monitors: no teams, schedules, escalation policies, contacts, or status pages. Use it when your source is not in the list above, or when you would rather hand-curate the monitor list than import everything and prune it back.

Both paths share the same safety rules: nothing is created until you confirm a selection, a failure on one row never stops the rest of the batch, and re-running is safe, HowlOps recognizes what it already created and skips it rather than duplicating or overwriting your later edits.

What generally comes over, and what generally does not

Across every supported provider, a few things are always true:

• Core monitor and check fields (URL or host, method, interval, timeout, and similar) import when the check type has a HowlOps equivalent. An interval faster than your plan's minimum is raised to that minimum and reported as a change, never silently dropped.
• On-call structure (teams, schedule rotations, overrides, and escalation policies) imports only when the shapes are truly equivalent. A rotation, override, or escalation rule that cannot be represented without changing who gets paged is left unsupported rather than approximated.
• People are matched by email. An existing HowlOps member is attached automatically; anyone else is offered as an optional invitation. Invited people show up as pending in imported teams, schedules, and escalation targets, but gain no access and receive no pages until they accept.
• Re-imports are idempotent. Each import remembers what it already created and skips it on a later run, so retrying after an interruption, or periodically re-checking for new items, never duplicates or overwrites something you have since edited in HowlOps.

And a few things are never true for any provider:

• Nothing is imported already turned on if it could page someone before you have verified it. Any monitor or object with a lossy or incomplete mapping is created paused or disabled, not live.
• Secrets, credentials, and anything that could contain them (API keys, integration tokens, webhook URLs, request headers, request bodies, URL usernames/passwords) are never copied. See the "What we never import, and why" section below.
• History (past alerts, incidents, and performance samples) does not import as live data that could re-trigger a notification. The one exception, Better Stack's already-resolved incident history, is explained in its row below.

Provider capability matrix

Provider	Imports	Does not import	Fidelity notes
UptimeRobot	HTTP, keyword, ping, TCP (from Port), heartbeat, and single-expectation DNS monitors; active maintenance windows (with a confirmed timezone); unpublished static status pages; contact and integration inventory (for manual reuse)	API, UDP, and Visual Comparison checks; multi-expectation DNS; monitor group membership as an access-control team (it becomes an informational tag instead); dynamic or password-protected status pages; subscribers, branding, custom domains; monitor and uptime history	Any monitor that must weaken a setting to import (for example, a raised interval) is created paused until you review and reactivate it.
Better Stack	Teams and pending invites; heartbeats; hourly/daily/weekly (and every-N) schedule rotations with overrides; linear escalation policies; HTTP, keyword, ping, and TCP monitors; unpublished status pages built from direct monitor components; already-resolved incident history (optional, capped at 10,000 rows) as inert historical record	Event-only or malformed rotations; policy branching, wait-until, and non-linear escalation steps; UDP/SMTP/POP/IMAP/DNS-server/Playwright monitor types; request headers, bodies, auth, and URLs with userinfo or query parameters; most status-page component types, branding, custom domains, and subscribers; active incidents and incident timeline/comments/attachments	Better Stack has no endpoint to list all teams; an otherwise-empty team needs a team-scoped run with a unique label. Imported incident history is inert: it never re-fires a notification.
Pingdom	HTTP and HTTP Custom, ping, and TCP port checks	DNS, UDP, SMTP, POP3, and IMAP checks; notification contacts and status pages (these are a short manual step, see the tutorial); probes/regions, delivery settings that don't map one-to-one, and check history	Intervals faster than your current plan minimum are clamped up and reported.
PagerDuty	Users (existing members matched by email, others invited); teams and roles; single-layer legacy schedules and overrides (up to a 366-day window you choose); a narrow exact subset of Shift-Based Schedules v3; escalation policies; services as business services (name, description, owner, escalation link); Event Orchestration and maintenance windows as read-only cutover inventory	Multi-layer or restricted legacy schedules; most Shift-Based Schedules v3 shapes; round_robin escalation with multiple targets; integration/routing keys; executable Event Orchestration; maintenance windows and priority labels as live objects; alerts, incidents, notes, and audit history; contact methods and personal notification rules	Selection is dependency-aware: picking a schedule also pulls in its team, picking a service pulls in its policy and team. A missing required dependency blocks the dependent row.
Opsgenie	Teams and membership; heartbeats; daily/weekly length-one schedule rotations with overrides; escalation policies (if-not-acked/if-not-closed rules); the exact AND/equality subset of team routing rules; a typed subset of alert and notification policies (imported disabled, for review); per-user notification rules as inventory only	Hourly and multi-period/end-dated/restricted rotations; routing rules using OR logic, regex, or time restrictions; complex or provider-template alert/notification policy behavior; per-user delivery steps and contact methods; integrations; alert and incident history; any continuous/recurring alert sync (this is a one-shot migration)	Opsgenie has no uptime monitors; if you also track uptime elsewhere, import that separately. A key must have configuration access, not just alert access, or preview returns 403.
Jira Service Management Operations	Teams (with full membership only if you supply an Organization ID); daily/weekly rotations with finite end dates and ongoing/future overrides; enabled heartbeats; escalation policies with user/schedule recipients; the exact AND/equality subset of routing rules; a typed subset of alert/notification policies (imported disabled, for review)	Team membership without an Organization ID (the team imports as an empty shell); team-admin role assignments (the API does not expose them); past overrides; multi-period or time-restricted rotations; integrations; alert and incident history	Team-role definitions are inventoried, but role assignment is not, so team-admin escalation recipients always fail closed rather than guessing.

What we never import, and why

Some things are excluded from every provider on purpose, not because of a temporary gap:

• The source provider's credentials. Your UptimeRobot, Better Stack, Pingdom, PagerDuty, Opsgenie, or JSM API key or token lives only in memory for the duration of the import job. There is no database column for it, and it never appears in a log or in the downloadable report.
• Request secrets. Custom HTTP headers, request bodies, HTTP auth values, and URLs that contain a username/password or (for some providers) query parameters are never copied, because any of them may hold a credential. Where a URL is otherwise safely imported, it is shown redacted in preview.
• ChatOps and integration credentials. Slack, Microsoft Teams, Discord, and other channel connections, OAuth grants, webhook URLs and secrets, and bot identities belong to your HowlOps workspace, not to data that can be carried over. You reconnect and re-authorize these after migration.
• Live alert, incident, and performance history. Historical records must never be able to re-trigger a notification or escalation. The one deliberate exception is Better Stack's already-resolved incident history, which imports as an inert record (timestamps, cause, ownership) with no ability to notify anyone.
• Other people's account-level identity. Passwords, SSO/SAML identities, personal contact methods, and personal notification rules belong to each individual user. HowlOps invites people by email; they bring their own verified identity and channels with them.
• Status page cosmetics and access controls. Passwords, custom domains, subscribers, branding, and custom code on a status page are not imported. Where a status page does import, it is always created unpublished so you can review it before it goes live.

See also

• Migrate from UptimeRobot
• Migrate from Better Stack
• Migrate from Pingdom
• Migrate from PagerDuty
• Migrate from Opsgenie
• Migrate from Jira Service Management Operations
• Bulk import monitors