ServicePulse
ServicePulse/Docs
RoadmapStart free
Documentation

ServicePulse Docs

Monitor third-party vendors, build a public status page, and get alerted when your dependencies go down.

Get started free Ask a question

Looking for the full reference docs?

This page is a quick-start guide. The complete API reference, advanced configuration, and integration guides live on our external docs site.

Full docs

Getting Started

Everything you need to know in your first 5 minutes.

What is ServicePulse?

ServicePulse monitors your third-party vendor dependencies — Stripe, AWS, Snowflake, GitHub, and 100+ others. When they go down, you know before your customers tell you.

It also lets you build a public status page so your customers can see your service health, and monitors your own HTTP endpoints and databases via heartbeat.

Adding your first vendor

Go to Vendors in the sidebar. Search for the service you depend on and click Track. ServicePulse polls their status page every 2–10 minutes (depending on your plan) and updates your dashboard automatically.

Your dashboard

The Dashboard shows a live overview of everything you track.
  • Green — operational, no issues
  • Yellow — degraded performance or partial outage
  • Red — major outage or active incident
Click any vendor to see its current incidents, component status, and recent history.

Vendor Monitoring

Track third-party services and get alerted when they have incidents.

Vendor catalog

Browse 100+ pre-configured vendors organized by category: cloud, payments, auth, data, communication, and more. Each vendor is pre-wired to poll the correct status API — you just click Track.

Filtering regions (e.g. Snowflake, AWS)

Some vendors have 50+ regions or components. When you click Track on a vendor like Snowflake, you'll be taken to the vendor page where you can select only the regions you actually use. Unselected regions are ignored for your dashboard and alerts — no noise from outages that don't affect you.

Custom vendors

Your vendor isn't in the catalog? Go to Vendors → Add custom vendor. Paste any Atlassian Statuspage or status.io URL and ServicePulse will poll it automatically.
Start with the vendors that would cause a customer-facing incident if they went down. Stripe, your database provider, your auth service, and your cloud provider are usually the most important.

Incidents

Track and understand active and historical vendor incidents.

Incident timeline

Click any vendor in your stack to see a real-time timeline of all updates for active incidents. Updates are polled directly from the vendor's status page.

AI summaries (Pro+)

ServicePulse uses Claude to read long incident threads and produce a single plain-English sentence:

"Stripe is experiencing elevated error rates on charge creation in the US-East region, affecting ~15% of API calls. Engineers are investigating."

AI summaries appear on the vendor page and in email notifications.

Incident history

The vendor detail page shows the last 5 resolved incidents. Your plan determines how far back you can look: Free (7 days), Pro (90 days), Team (1 year).

Notifications

Get alerted when vendors go down — before your customers notice.

Setting up notifications

Go to Settings → Notifications. Enter your email, Slack webhook URL, Teams webhook URL, or PagerDuty integration key. You can configure which events trigger alerts: new incident, incident updated, incident resolved.

Notification channels by plan

ChannelPlan required
EmailPro+
Microsoft TeamsPro+
DiscordPro+
SlackTeam+
PagerDutyTeam+
Outbound WebhookTeam+
Google ChatTeam+
ZapierTeam+
Jira AutomationTeam+

All channels apply to both vendor incidents and your own ping monitor alerts.

Uptime & Endpoint Monitoring

Monitor your own services, jobs, and databases.

HTTP monitors

Enter a URL (e.g. https://api.yourapp.com/health) and ServicePulse pings it at regular intervals. If it returns an unexpected status code or times out, you get an alert. Supports GET, HEAD, and POST.

Heartbeat monitors

For background jobs, cron tasks, and queue workers that aren't HTTP-accessible.

You get a unique URL. Your job calls it at the end of each run. If ServicePulse doesn't hear from it within 2× the expected interval, the monitor turns red and you get alerted.

Example: a nightly backup job that runs at 2am. If it doesn't check in by 2:10am, you know something went wrong.

Database monitoring

ServicePulse can't reach your private database directly — it's behind a firewall or VPC. Instead, run a small script on your server that:
  1. Connects to your database
  2. Runs a health query (e.g. SELECT 1)
  3. Pings the ServicePulse heartbeat URL if successful

When you create a Database monitor, ServicePulse generates copy-paste scripts for PostgreSQL, MySQL, Python, and Node.js. You can customize the query — for example, check that a table has been updated in the last 10 minutes.

Alert thresholds

By default, a monitor alerts after the first failure. You can change this under Monitor → Alert Settings.

Setting "alert after 2 consecutive failures" means a single blip won't wake anyone up — only a sustained outage will. Recovery alerts (when the monitor comes back up) can also be toggled independently.

Monitor detail page

Click any monitor in Ping Monitors to open its detail page:
  • 24h and 90-day uptime percentages
  • Average and p95 response time
  • Response time chart (90 days)
  • Day-by-day uptime calendar with 7/30/90d toggle
  • Full incident log with duration and cause
A self-hosted monitoring agent (for running SQL health checks inside your VPC without a cron script) is on the roadmap for Q3 2026.

Status Pages

Give your customers a public place to check your service health.

Your public status page

Go to Status Page in the sidebar. Your page is published at yourslug.servicepulse.dev. You can also configure a custom domain (e.g. status.yourcompany.com).

Services and dependencies

Define your services (e.g. "API", "Payments", "Mobile App"). Link each service to the vendors it depends on. Your status page shows the computed worst-case status for each service based on live vendor health.

Example: "Payments" depends on Stripe. If Stripe has a partial outage, your Payments service shows degraded automatically.

Embeddable widget

Add a live status badge to your own site or docs:

<iframe src="https://yourslug.servicepulse.dev/widget" />
Copy the embed code from the Status Page settings page.

Linking a ping monitor to a service

Under Status Page → Services, expand a service and select a ping monitor from the dropdown. If that monitor goes down, the service automatically shows as Major Outage on your public page — no manual update needed.

Incidents API (Pro+)

Post incidents programmatically from Datadog, PagerDuty, or any tool that can send an HTTP request. Generate your Status Page Posting Key under Developers. Then POST to:
POST /api/status-page/[slug]/incidents
Include your Bearer token and a JSON body with title, body, and status.

Custom CSS for Status Pages (Business)

Business plan only. This is available under Status Page → Settings.

Use the Custom CSS textarea to override the look of your public and secure status pages.
Your CSS is applied inside the status page component; use the documented hooks below for predictable styling.

ServicePulse sets these CSS variables on the page:
  • --bg — the status page background
  • --fg — the status page text color
  • --accent — the status page accent color

Documented CSS hooks (stable):
  • .sp-status-page — top-level status page container
  • .header — the page header area
  • .service-item — each service card row
  • .sp-overall-banner — overall status banner
  • .sp-overall-banner-dot — status dot inside the overall banner
  • .sp-overall-banner-label — banner label text
  • .sp-maintenance-banner — maintenance banner (and children like ...-title, ...-item)
  • .sp-maintenance-banner-title — maintenance banner title
  • .sp-maintenance-banner-list — list container
  • .sp-maintenance-banner-item — each maintenance entry
  • .sp-maintenance-banner-link — “View all maintenance…” link
  • .sp-incident-card — each incident details card (active + historical)
  • .sp-incident-card--historical — historical incident card styling (Recent Updates)
  • .sp-incident-summary — incident summary row (title + status badge + timestamp)
  • .sp-incident-body — incident body shown when expanded
  • .sp-incident-created-at — timestamp on the incident summary row
  • .sp-incident-resolved-at — resolved timestamp (historical incidents)
  • .sp-incident-status — incident status badge
  • .sp-service-history — the 30-day history region inside each service card
  • .sp-service-history-item — the service card wrapper when history is enabled
  • .sp-service-history-summary — the summary row inside the service card
  • .sp-service-name — service name text
  • .sp-service-history-toggle — “30-day history” toggle text
  • .sp-service-history-header — “Last 30 days” header row
  • .sp-service-history-day — each 30-day day cell in the history strip
  • .sp-service-history-days — strip/container for the day cells
  • .sp-embed-snippet-toggle — “Embed this status page” summary
  • .sp-embed-snippet-body — embed snippet body
  • .sp-embed-snippet — the “Embed this status page” widget

You can override variables and/or target any elements inside the page. Example:.sp-status-page { background: var(--bg); color: var(--fg); } .sp-status-page .header { border-bottom: 0; } .sp-status-page .service-item { padding: 20px; } .sp-overall-banner { border-width: 0; } .sp-overall-banner-dot { border-radius: 9999px; } .sp-maintenance-banner-title { text-transform: uppercase; } .sp-incident-card { border-color: rgba(37, 99, 235, 0.25) !important; } /* You can also override variables like: */ /* .sp-status-page { --accent: #22c55e; } */

Custom numeric metrics on public status pages (Pro+)

ServicePulse supports user-defined numeric metrics (time series) that you post via API. These charts are shown on your public status page under Status Page → Metrics.

Posting requires your Status Page Posting Key (same key as the Incidents API).
POST /api/status-page/<slug>/metrics Authorization: Bearer <your-posting-key> Content-Type: application/json { "metric": "web_traffic", // stable key you pick "value": 120, // number "timestamp": "2026-03-17T14:22:00Z", // optional ISO string (defaults to now) "unit": "req/s", // optional (stored and shown in charts) "label": "Web traffic" // optional (stored as display name) }
Notes:
  • First ingest will upsert the metric and create the public chart configuration if needed.
  • You can remove metrics from Status Page → Metrics; ingesting again may re-add them.

Trust Portal / Subprocessors

On the vendor detail page, click Add to Trust Portal to mark a vendor as a subprocessor. Your trust portal is published at yourslug.servicepulse.dev/trust. Share this URL with customers and prospects to demonstrate GDPR compliance.

Metrics

Uptime history and response time charts — for your vendors and your own monitors.

Vendor metrics

Every time ServicePulse polls a vendor, it records the response time and up/down status. Open any vendor page to see:
  • A response time chart (avg and p95) with a 7/30/90-day toggle
  • A day-by-day uptime calendar color-coded by worst status

Ping monitor metrics

HTTP ping monitors record latency on every check. The monitor detail page shows the same response time and uptime charts, calculated from your own check results rather than the vendor's status page.

Metrics on your public status page

In Status Page → Metrics, opt in to show charts publicly. You can add any tracked vendor or ping monitor. For each one, toggle uptime and/or response time independently.

Visitors to your status page see the charts with the same 7/30/90-day toggle.

Uptime & SLA comparison

The Uptime page shows all your tracked vendors side-by-side: uptime %, SLA target, and whether they're meeting it. Set a custom SLA target per vendor under its detail page.

Push & Webhooks

Receive incident data from vendors that push rather than publish.

Inbound push webhooks

Some vendors (e.g. custom tools, PagerDuty) can push incident data to you instead of publishing a status page. Create a push endpoint under the Push tab. You get a unique URL to paste into the vendor's webhook configuration.

Organizations

Share monitoring with your whole team. Requires Team plan.

Creating an organization

Go to Organization in the sidebar. Click Create Organization, enter a name, and invite teammates by email. Once you switch to the org context (via the switcher in the top bar), all monitored vendors, services, and alerts are shared.

Switching between personal and org

Use the organization switcher in the top bar to toggle between your personal account and your organization. Your personal stack and your org stack are kept separate.
Role-based access control (admin/editor/viewer) is on the roadmap. Currently all org members have full access.

My Services

Internal view of your own products and their vendor dependencies.

What are services?

Services represent your own products — "Checkout API", "Mobile App", "Data Pipeline". Each service has vendor dependencies. The service's status is the worst-case status of all its dependencies.

My Services vs. Status Page

My Services is your internal view — all the technical detail, component-level status, dependency chains.

Status Page is the public-facing view your customers see — simplified, with only the services you choose to expose. Configure which services appear publicly under Status Page → Settings.

API Reference

Automate status updates, post incidents, and integrate with your existing tooling.

Authentication

ServicePulse exposes three types of API tokens:
  • Personal API token — account-level Bearer token. Generate one under Developers in the sidebar. Pass as Authorization: Bearer sp_....
  • Status page posting key — a Bearer token scoped to a single status page. Generate it under Developers → Status Page Posting Key.
  • Push endpoint token — embedded directly in the ingest URL (/api/ingest/<token>). No Authorization header needed. Create one under Push in the sidebar.

Push webhook endpoint

Receive incident data from external tools by creating a push endpoint. Go to Push in the sidebar, create an endpoint, and paste the URL into your external tool's webhook configuration.

POST https://servicepulse.dev/api/ingest/<token>
ServicePulse auto-detects the payload format. Supported formats:
  • Native ServicePulse JSON
  • Atlassian Statuspage (incident / component_update webhooks)
  • PagerDuty webhook v3
  • Alertmanager (Prometheus)
  • Datadog alert webhooks — fires when a monitor alert triggers or recovers
  • New Relic alert webhooks — fires on policy condition state changes
  • Jira Automation (incoming webhook)

Note on Datadog & New Relic: these integrations receive alert/incident events (monitor fired, policy breached), not raw time-series metrics. Full metric ingestion (response times, error rates) from external APM tools is on the roadmap.

Native push payload

If you're sending from your own tooling, use the native format:

POST /api/ingest/<token> Content-Type: application/json { "status": "degraded", // operational | degraded | outage | maintenance "title": "API latency spike", "message": "p95 latency is elevated in us-east-1", "severity": "minor" // info | minor | major | critical }

Status page incidents API

Post, update, and resolve incidents on your public status page programmatically.

Create incidentPOST /api/status-page/<slug>/incidents Authorization: Bearer <your-api-key> Content-Type: application/json { "title": "Elevated error rates", "body": "We are investigating reports of elevated error rates.", "status": "investigating", // investigating | identified | monitoring | resolved "severity": "major" // minor | major | critical }Update incidentPATCH /api/status-page/<slug>/incidents/<id> Authorization: Bearer <your-api-key> Content-Type: application/json { "body": "Fix has been deployed. Monitoring.", "status": "monitoring" }Resolve incidentPATCH /api/status-page/<slug>/incidents/<id> Authorization: Bearer <your-api-key> Content-Type: application/json { "body": "Fully resolved as of 14:32 UTC.", "status": "resolved" }

curl examples

Create a new incident from a shell script:curl -X POST https://servicepulse.dev/api/status-page/acme/incidents \ -H "Authorization: Bearer sp_a1b2c3d4e5f6..." \ -H "Content-Type: application/json" \ -d '{"title":"Database degraded","status":"investigating","severity":"major"}'Push a status update from CI/CD:curl -X POST https://servicepulse.dev/api/ingest/<token> \ -H "Content-Type: application/json" \ -d '{"status":"operational","title":"Deploy complete","severity":"info"}'

Outbound webhook payload

When you configure an outbound webhook (Settings → Notifications → Outbound Webhook), ServicePulse sends a signed POST request on each trigger:

POST <your-webhook-url> X-ServicePulse-Signature: sha256=<hmac-sha256-hex> Content-Type: application/json { "vendor_name": "Stripe", "status": "major_outage", "incident_title": "Elevated API error rates", "incident_description": "Stripe is reporting elevated error rates...", "timestamp": "2026-03-17T14:32:00.000Z" }
The signature uses HMAC-SHA256 with your webhook secret as the key. Verify it to confirm the payload came from ServicePulse.
All API endpoints require HTTPS. Your Status Page Posting Key is shown once at creation — store it in a secret manager (e.g. GitHub Actions secrets, AWS Secrets Manager).

Something missing or unclear? Contact support or check the roadmap.

Need deeper reference docs? docs.servicepulse.dev →