Administration·8 min read

Integrations

Connecting monitoring, alerting, ticketing, and paging tools to PulseServe.

PulseServe is built to sit downstream of your existing tools rather than replace them — it ingests signal from what you already run and can keep records in sync with your existing ITSM system, rather than asking you to migrate everything in on day one.

Monitoring & paging

Prometheus — metric-based alert ingestion feeding the Signal Correlator.
Grafana — alert webhooks and dashboard linking for MELT context on an incident.
PagerDuty / Opsgenie — paging-channel integration alongside native Slack and email (configured under Notifications, Paging & SSO).
Custom webhooks — a generic inbound path for any tool that can POST an alert or MELT payload.

All of these authenticate the same way — an issued API key pasted into the sending tool, set up from Admin → API Keys (see Notifications, Paging & SSO).

Syncing with an external ITSM tool

Settings → Integrations connects PulseServe bidirectionally with ServiceNow, Jira Service Management, and Jira Software — set up as three independent connections, not a single either/or choice, so you can run more than one at once if you need to. Per connection, enter the instance URL and credentials and click Test Connection, then independently enable inbound sync, outbound sync, and a polling interval for each record type the connection supports (incidents, changes, problems, configuration items, knowledge articles, and users, depending on the tool). An inbound webhook is also available for near-real-time updates instead of waiting for the next poll.

ServiceNow additionally offers a field-mapping editor — a table of default field pairings (PulseServe field ↔ ServiceNow field) you can override, or extend with your own custom pairs. Jira's connections don't expose a mapping editor; their sync uses a fixed field correspondence. On any individual incident, change, or problem, a small sync-status badge shows whether it's synced, in conflict, or errored for each connected system, and lets you force a one-off re-sync of just that record without waiting for the next scheduled poll.

Choosing a CMDB graph backend

Also on the Integrations page, separate from the three ticketing connectors above: which database actually powers CMDB topology and blast-radius lookups. The built-in option (backed by your existing Postgres database) works out of the box with no setup. Apache AGE is a real, working alternative graph backend with its own status check and resync button, useful at larger CMDB scale.

An ArangoDB tab exists so the connection details are ready ahead of time, but it isn't functional yet — selecting it shows a clear warning that CMDB lookups are still actually running on the built-in backend underneath. Stick with the built-in option or Apache AGE for now.

Example

An organization migrating off ServiceNow connects it under Settings → Integrations, enables inbound and outbound sync for Incidents and Changes, and adds a custom field-mapping override for a field their old instance renamed. For the next few months, tickets created in either system stay in sync automatically — and when one record needs to jump the queue, someone just clicks its sync badge to force an immediate re-sync — letting teams cut over gradually instead of a hard switchover.