> This is part 1 of 3 of the full documentation (pages 1–100 of 266). > The content is paginated: fetch every part to see all of it. > Next part: https://docs.spike.sh/llms-full.txt/1 > Page index: https://docs.spike.sh/llms.txt # Introduction Documentation for Spike's incident management platform — integrations, on-call schedules, escalation policies, Playbooks, and status pages. Spike is an incident management platform for on-call teams. These docs cover setting up integrations, on-call schedules, escalation policies, Playbooks, and status pages. For questions or feedback, email . ## Spike basics


Incident management	Track and respond to incidents from one place	What is an incident?	incident card cover.png
On-call schedules	Set up rotations so the right person is always on call	Introduction to On-call schedules	oncall card cover.png
Alerts	Phone calls, SMS, Slack, Microsoft Teams, and more	Phone alerts	Alerts card cover.png
Escalations	Route alerts through a policy until someone responds	Escalation policies	Escalations card cover.png
Integrations	Connect your monitoring tools to trigger incidents in Spike	Create integration and service on our dashboard	Integrations card cover.png
Playbooks	Automate response actions when incidents occur	Playbooks	Automation card cover.png
Status pages	Publish system status updates for customers	Create a status page	Statuspage card cover.png
Collaboration	Connect task management and helpdesk tools to incidents	Task management integrations	Collaboration card cover.png
Administration	Manage team members, roles, and access	Roles and access	Administration card cover.png

# What is Spike? Spike is an on-call and incident management platform that alerts the right person when something breaks in your infrastructure. Spike is an on-call and incident management platform. When a monitoring tool detects an issue, Spike creates an incident. Then, it alerts the right person and escalates until someone responds. ## How Spike works Every incident starts with an integration. When a connected monitoring tool detects a problem, it sends a signal to Spike. Spike creates an incident and triggers your escalation policy, which determines who gets alerted and through which channel. If no one responds in time, Spike moves to the next person in line. Once resolved, reports capture the data so your team can track patterns over time. ## Core modules ### Integrations Spike connects to [over 100 monitoring, logging, and observability tools](/integrations-guideline/setup-integrations). Each integration gets a unique token, so incidents from different sources stay separate. You can add as many integrations as you need with no restrictions. {% hint style="info" %} Don't see an integration you need? Email and we'll build it. {% endhint %} ### Services

Services on Spike — Services map to components in your infrastructure.

Services map to components in your infrastructure: a backend API, a payment service, a worker queue. Each service holds multiple integrations. When an incident fires, Spike shows which service is affected and its current health status based on open incidents. You can create as many services as you need to reflect your full architecture. ### Escalations

Escalation policies on Spike — Create separate escalation policies for teams, services, or situations.

An [escalation policy](/escalations/introduction-to-escalations) defines who gets alerted and in what order. You can build separate policies for different teams or services. If the first person doesn't acknowledge in time, Spike moves down the policy until someone responds. ### Alerts Spike reaches your team through phone calls, SMS, email, Slack, Microsoft Teams, WhatsApp, Telegram, Discord, and Pushover. Each person sets their own alert preferences. [Alert rules](/alerts/alert-rules) let you route, filter, and prioritize alerts automatically based on incident properties. ### On-call schedules [On-call schedules](/oncall-schedules/introduction-to-on-call-schedules) control who is on-call at any given time. Build schedules with layers and slots, set up overrides for coverage gaps, and sync shifts to Google Calendar, Apple Calendar, or Outlook. ### Playbooks [Playbooks](/playbooks/introduction-to-playbooks) automate the repetitive work that happens when an incident fires. Create a war room, open a Jira ticket, update your status page. Playbooks run these steps automatically so your team can focus on the fix. {% hint style="info" %} To see Spike in action, book a call at [calendly.com/spikehq](https://calendly.com/spikehq) or email . {% endhint %} # What is an incident? An incident is any issue that needs investigation and resolution, often one that affects your customers or systems. An incident is any issue that needs to be investigated and resolved. When a connected monitoring tool detects a problem, Spike creates an incident and alerts the right person based on the [escalation policy](/escalations/introduction-to-escalations) attached to that integration. ## Examples Common examples of incidents include: * CPU or memory utilization crossing a critical threshold * Database monitoring alerts * Database backup failures * Billing process failures * Notification delivery failures * Dashboard loading errors * Website downtime {% hint style="info" %} You can also create incidents directly from your code using a [webhook integration](/integrations-guideline/integrating-with-webhooks). {% endhint %} ## Incident statuses Every incident has one of three statuses. See [incident statuses](/incidents/incident-statuses) for the full breakdown.

Incident statuses on Spike — The three incident statuses: Triggered, Acknowledged, and Resolved.

### Triggered A triggered incident means Spike has detected a problem and is actively alerting. Spike works through the escalation policy, sending alerts until someone acknowledges or resolves the incident. Repeat incidents are automatically suppressed to reduce [alert fatigue](/alerts/personal-alerts-management). ### Acknowledged An acknowledged incident means someone is working on a fix. Spike stops alerting and pauses the escalation policy. You can optionally set an [acknowledge timeout](/incidents/acknowledge-timeout): a time limit after which Spike moves the incident back to triggered and resumes alerting if it hasn't been resolved. ### Resolved A resolved incident means the issue is fixed. Spike stops all alerts and resets the escalation policy for any future incidents on that integration. # Incident lifecycle The incident lifecycle covers the stages an incident moves through, from the moment it's triggered to when it's resolved. Every incident on Spike moves through a defined set of stages. Understanding this flow helps you configure escalation policies, acknowledge timeouts, and alert channels to match how your team actually responds.

Incident lifecycle on Spike — The stages of an incident on Spike.

## 1. Incident creation An incident is created when a connected integration sends a webhook to Spike. Before creating a new incident, Spike checks whether an open incident already exists for that integration. * If one exists, Spike logs the new event under the existing incident instead of creating a duplicate. * If no open incident exists, Spike creates a new one and starts the escalation process. {% hint style="info" %} Only open incidents (triggered or acknowledged) are checked for duplicates. Resolved incidents are ignored. {% endhint %} ## 2. Incident escalation Once an incident is created, Spike works through the [escalation policy](/escalations/introduction-to-escalations) attached to that integration. Alerts go out to the first set of responders in the policy. Spike waits for the duration configured in the escalation policy. If no one acknowledges or resolves the incident in that time, Spike moves to the next level and alerts the next set of responders. Each integration can have its own escalation policy. This lets you set different alert priorities across services. ## 3. Incident acknowledgment When a responder acknowledges the incident, Spike pauses the escalation policy and stops escalating alerts. You can set an [acknowledge timeout](/incidents/acknowledge-timeout) for each integration: a time limit that moves the incident back to triggered and resumes alerting if it hasn't been resolved in time. You can also manually move an acknowledged incident back to triggered at any time. ## 4. Incident resolution Once the issue is fixed, mark the incident as resolved. Spike stops all alerts and resets the escalation policy. If a new incident comes in for the same integration, the process starts again from the beginning. See [incident statuses](/incidents/incident-statuses) for a full reference on each status. # Incident statuses Every incident on Spike has one of three statuses: triggered, acknowledged, or resolved. The status determines what Spike does next. Every incident on Spike moves through three statuses: triggered, acknowledged, and resolved. The current status determines whether Spike is actively alerting, paused while someone works on a fix, or closed. ## Triggered An incident enters the triggered state the moment it's triggered. This means no one has looked at it yet and the problem is unresolved. In this state, Spike works through the [escalation policy](/escalations/introduction-to-escalations) attached to the integration and sends alerts to the designated responders. Alerts continue until someone acknowledges or resolves the incident. Repeat incidents from the same integration are suppressed and logged rather than creating new ones. ## Acknowledged An acknowledged incident means someone is actively working on a fix. Spike pauses the escalation policy and stops escalating alerts. Repeat incidents remain suppressed in this state to reduce [alert fatigue](/alerts/personal-alerts-management). You can set an [acknowledge timeout](/incidents/acknowledge-timeout) for each integration. If the incident isn't resolved within that window, Spike moves it back to triggered and resumes alerting. You can also manually move an acknowledged incident back to triggered at any time. ## Resolved A resolved incident means the issue is fixed. Spike stops all alerts and resets the escalation policy. If the same integration triggers a new incident after resolution, Spike treats it as a fresh incident and starts the process from the beginning. See [incident lifecycle](/incidents/incident-lifecycle) for the full flow. # How to change incident status Change an incident's status directly from any alerting channel — SMS, phone, Slack, or email — without opening Spike. You can change an incident's status from all alerting channels without having to come to Spike. ## From the dashboard

Select one or more incidents on the dashboard — Select incidents and change their status from the dashboard.

Open the [dashboard](https://app.spike.sh) to see all open incidents. Select an incident using the checkbox on the left, then click **Acknowledge** or **Resolve** at the top. ### Multiple incidents Select multiple incidents using the checkboxes, or use the dropdown to select all incidents matching a specific criteria. Then apply the status change in bulk. ## From a phone call During a [phone alert](/alerts/phone), press a key to take action immediately: 1. **Press 4** to acknowledge 2. **Press 6** to resolve 3. **Press 9** to escalate You'll hear a voice confirmation on the same call once the status changes. ## From Slack

Acknowledge and resolve incidents from Slack — Slack alerts include Acknowledge and Resolve buttons.

Every [Slack alert](/alerts/slack) includes **Acknowledge** and **Resolve** buttons. When you change the status, all related Slack messages update to reflect it. This applies regardless of whether the change was made via phone, email, SMS, or the dashboard. ## From email Reply to a [Spike email alert](/alerts/email) with one of the following: 1. **#ack** to acknowledge 2. **#res** to resolve No confirmation is sent after the status change. ## From SMS Send an SMS from your registered phone number to change status. You don't need to reply to a Spike message — just send a new one: 1. **#\ ack** to acknowledge (example: `#1226 ack`) 2. **#\ res** to resolve (example: `#2071 res`) This works even if [SMS](/alerts/sms) is not in your escalation policy. Spike processes the action as long as you send from your registered number. ## From mobile The dashboard and incident detail pages are mobile-compatible. Visit [app.spike.sh](https://app.spike.sh) on your mobile browser to view open incidents and change their status. # Acknowledge timeout Acknowledge timeout automatically moves an acknowledged incident back to triggered state if it isn't resolved within a set time. Acknowledge timeout is a time limit you set on an integration. If an acknowledged incident isn't resolved within that window, Spike moves it back to triggered state and resumes alerting. This is useful when someone acknowledges an incident but gets pulled into other work before resolving it.

Acknowledge timeout setting — Set acknowledge timeout in minutes on any integration.

## What timeout should you set? It depends on how critical the integration is. A shorter timeout means faster re-alerting on unresolved incidents. * **Critical integrations** — 20 minutes * **Severe but non-critical integrations** — 60 minutes * **Non-critical integrations** — leave it blank You don't need a timeout on every integration. {% hint style="warning" %} Avoid short timeouts like 5 or 10 minutes. They generate more alerts than your team can act on and increase alert fatigue. {% endhint %} # Grouping incidents Spike automatically groups repeated incidents so you can see how often an issue recurs and when it first appeared. When the same incident fires multiple times, Spike groups them under the original incident rather than creating new ones. This keeps your dashboard clean and gives you a clear picture of how often an issue is recurring.

Grouped incidents on Spike — Repeated incidents are grouped under the original with a repeat count.

Each grouped incident shows: * How many times it has repeated * When it first occurred * When it last occurred * When each recurrence happened This helps you judge whether an issue is a one-off or a pattern. If an incident has repeated dozens of times, it's likely affecting your customers and worth prioritizing over something that fired once. # Priority and severity Priority indicates how urgently an incident needs to be resolved. Severity indicates the degree of damage to your systems. Not all incidents need immediate action. Priority and severity give your team two ways to classify an incident: how urgent it is to fix, and how much damage it's causing. ## Priority Priority indicates the urgency to resolve an incident. Available priorities are: * **P1**: Urgent * **P2**: High * **P3**: Medium * **P4**: Low * **P5**: Info For example, a billing service outage is a P1. A database server running low on storage might be a P2. ## Severity Severity indicates the degree of damage to your systems. Available severities are: * **SEV1**: High * **SEV2**: Medium * **SEV3**: Low For example, a data leak or full service outage is a SEV1. A degraded non-critical service might be a SEV3. {% hint style="info" %} Once you set priority and severity on an incident, Spike remembers them for future occurrences of the same incident. {% endhint %} ## Setting priority and severity ### From the dashboard Select one or more incidents. The priority, severity, and mute options appear at the top of the list.

Set priority on multiple incidents from the dashboard — Select incidents from the dashboard to set priority and severity in bulk.

### From the incident page Open any incident to find the priority and severity options on the incident detail page.

Set priority from the incident page — Set priority and severity directly from the incident page.

### From integrations Some integrations, like Azure, send priority and severity as part of their incident payload. Spike reads these values and sets them automatically, overwriting any existing values. You can also send priority and severity via [webhook integration](/integrations-guideline/integrating-with-webhooks). ### From alert rules and Playbooks You can set priority and severity automatically using [alert rules](/alerts/alert-rules) based on incident properties. [Playbooks](/playbooks/introduction-to-playbooks) can also set them as part of an automated response when an incident fires. ## FAQ ### Should I set both priority and severity? For critical incidents, yes. For lower-signal integrations, you can use just one or neither. Both fields are optional. ### Who can set priority and severity? Everyone on the team. There are no restrictions on who can set or change these fields. ### Can I set priority and severity automatically? Yes. Use [alert rules](/alerts/alert-rules) to set them based on incident properties, or connect integrations like Azure that send these values automatically with each incident. # Mute alerts Mute alerts on an incident to stop repeat notifications for a set period, without resolving the incident itself. Muting stops all alerts for an incident and its repeated occurrences for a set period. The incident stays open and logged. Spike just stops notifying your team about it. This is useful for low-priority incidents you're aware of but don't need to act on immediately. Instead of getting alerted repeatedly, you mute it and come back when you're ready.

Mute alerts on an incident for a set duration.

## Mute duration options * 1 hour * 10 hours * 1 day * 1 week * 1 month * Forever {% hint style="warning" %} Use **Forever** carefully. Muting an incident permanently means your team will never be alerted about it again, even if it keeps recurring. {% endhint %} # Reassign incidents Reassign any incident to a different team member directly from the dashboard, incident page, or service view page. You can reassign any incident to a team member. Once reassigned, they receive an email notification. ## How to reassign Select one or more incidents and click **Reassign** in the incidents table header.

Reassign button on the incidents table — The Reassign button appears in the incidents table header after selecting an incident.

Reassign responders modal — Add or remove responders from the reassign modal.

The reassign option is available from: * Incidents page * Inside the incident {% hint style="danger" %} You cannot reassign an incident to a team member with the **Support** role. {% endhint %} ## Effect on escalations Reassigning an incident does not affect the escalation policy. The policy continues running as configured. # Sharing incidents Share any Spike incident as a public link with customers, stakeholders, or your team to communicate an outage. You can share any incident as a public link. This is useful for communicating outages to customers or embedding status updates in your docs. ## Enable public sharing Public sharing is off by default. To turn it on, go to [Alerts under organisation settings](https://app.spike.sh/settings/general/alerts) and enable it for your organisation.

Enable public sharing from organisation settings.

{% hint style="info" %} If you disable public sharing in organisation settings, all existing public incident links become private immediately. {% endhint %} ## How to share an incident Open an incident and click the **Share** button on the right-hand side of the incident details page.

Share an incident as a public link — Click Share on the incident details page to get a public link.

{% hint style="info" %} Each incident has a unique public link. The link stays the same regardless of how many times you toggle sharing on or off. {% endhint %} # Why does message parsing fail? Message parsing fails when Spike can't convert an integration's JSON alert payload into a readable incident format. When an integration triggers an incident, Spike parses the JSON payload into a readable format. Some integrations send payloads in formats the parser doesn't recognise, and that's when it fails.

Example of incident message parsing fail — An incident with a failed message parse in the incidents table.

## Does it affect alerts? Yes. Alerts still go out, but the incident message won't be included. ## Does it affect the incident? No. The incident is still created and all details are available. Click the incident ID to view the full details. ## Report a parsing failure When you see a parsing failure, report it with a single click. Each report helps improve the parser for future incidents.

Report a parsing failure with a single click — Report a parsing failure directly from the incidents table.

{% hint style="warning" %} Once the parser is fixed, existing incidents won't be updated. The fix applies to new incidents only. {% endhint %} # Rate limiting on duplicate incidents Spike rate-limits duplicate incidents to reduce noise when the same incident triggers repeatedly in a short window. Rate limiting kicks in when the same incident triggers too many times in a short window. It prevents your team from being overwhelmed with duplicate alerts. ## How it works If an incident triggers 20 or more times within 60 seconds, Spike rate-limits it for one minute. During that window, duplicate incidents are suppressed. After one minute, rate limiting is lifted and new incidents from the same integration are allowed through again. ## FAQs ### What counts as a duplicate incident? Incidents with the same title are considered duplicates. ### Does rate limiting affect other incidents? No. Rate limiting applies to a specific incident, not the integration. All other incidents on the same integration continue to trigger normally. ### Will I be notified when rate limiting applies? Yes. Admins receive an email alert when rate limiting kicks in. However, Spike sends no more than one email every 30 minutes. ### Will any incidents be missed? No. An incident has to trigger 20 or more times within 60 seconds for rate limiting to apply. You would have received an alert for the very first occurrence. ### Is any action needed to lift rate limiting? No. Rate limiting is automatic. It lifts itself after one minute. # Resolve by Timer Resolve by Timer automatically resolves incidents after a set duration if they haven't been manually resolved.

Resolve by Timer feature on Spike — Resolve by Timer on Spike.

## What is Resolve by Timer? Resolve by Timer automatically resolves an incident after a set duration. When an incident triggers, a countdown starts. If the incident isn't resolved before the countdown ends, Spike marks it as **Resolved by Timer**. You can cancel the timer at any point from the incident view. You can set up Resolve by Timer in three ways: * **Integration level**: applies to all incidents from an integration * **Alert rules**: applies only when certain conditions are met * **Playbooks**: applies as part of your response playbook {% hint style="success" %} Resolve by Timer is available on all plans. {% endhint %} ## How it works

Timer in different states on an incident — The timer countdown visible on an incident.

When an incident triggers, a countdown begins automatically. The incident behaves normally during this time. It can be acknowledged, updated with notes, or manually resolved at any time. If the countdown ends and the incident is still open, Spike marks it as **Resolved by Timer**. A badge and countdown indicator appear on the incident row and detail page.

Badge showing incident was resolved by timer — The badge shows the incident was resolved by timer.

## How to set up Resolve by Timer on an integration **Best for:** Applying the same timer to all incidents from a specific integration. {% stepper %} {% step %} When editing or creating your integration, scroll to **Advanced Configuration** and locate the **Resolve by Timer** toggle. {% endstep %} {% step %} Toggle **Resolve by Timer** on, enter your time value, select the unit (**Minutes**, **Hours**, or **Days**), and click **Save**. {% endstep %} {% endstepper %}

Resolve by Timer setup in integration settings — Setting Resolve by Timer at the integration level.

## How to set up Resolve by Timer with alert rules **Best for:** Applying timers only to incidents that meet specific conditions. {% stepper %} {% step %} While editing or creating an alert rule, set up your conditions to define which incidents the rule applies to. {% endstep %} {% step %} In **Actions**, select **Resolve by Timer**. Enter the time value and select the unit (**Minutes**, **Hours**, or **Days**), then save or update the rule. {% endstep %} {% endstepper %}

Resolve by Timer setup in alert rules — Setting Resolve by Timer via alert rules.

## How to set up Resolve by Timer in playbooks **Best for:** Including a timer in your incident response workflow. {% stepper %} {% step %} While editing or creating a playbook, add an action to apply Resolve by Timer. {% endstep %} {% step %} Choose when the timer should start: immediately on trigger, or when the incident status changes to **Acknowledged**. {% endstep %} {% endstepper %}

Resolve by Timer setup in playbooks — Setting Resolve by Timer via playbooks.

## FAQs ### Can I remove the timer for a specific incident? Yes. Click the remove timer button on the incident to cancel it. ### Can I set different times for different severity levels? Yes. Use alert rules to apply different timers based on incident severity. ### What is the minimum resolution time? 1 minute. For most use cases, 15 to 30 minutes is a more practical minimum. ### Will I be notified when an incident resolves by timer? This depends on your notification settings. You can configure alerts for resolved incidents. # Phone alerts Spike calls your phone when an incident triggers — press a key during the call to acknowledge, resolve, or escalate it. When an incident triggers, Spike calls your phone. During the call, press a key to take action: 1. Press **4** to acknowledge 2. Press **6** to resolve 3. Press **9** to escalate

Check if your country or region supports phone calls on the [geo permissions page](https://app.spike.sh/geo-permissions). {% hint style="info" %} Make sure to verify your phone number before setting up phone alerts. You can update it in your [profile settings](https://app.spike.sh/settings/profile). {% endhint %} # SMS alerts Spike sends an SMS the moment an incident triggers, so you stay informed of critical issues without a phone call. Spike sends an SMS when an incident triggers.

## Change incident status via SMS You can acknowledge or resolve an incident by sending an SMS from your registered phone number. Send a new message (not a reply) with the incident ID: 1. **#\ ack** to acknowledge (example: `#1226 ack`) 2. **#\ res** to resolve (example: `#2071 res`) Check if your country or region supports SMS on the [geo permissions page](https://app.spike.sh/geo-permissions). # Mobile app alerts Spike's mobile app delivers real-time incident alerts to your phone, with support for critical notifications on iOS and Android.

Spike mobile app showing incident alerts — Spike mobile app alerts.

Spike's mobile app sends real-time incident alerts to your phone. Download the app, log in, and allow notifications to start receiving alerts. {% tabs %} {% tab title="iOS" %}

[Download the iOS app](https://apps.apple.com/au/app/spike-sh/id1586777789) from the App Store. {% endtab %} {% tab title="Android" %}

[Download the Android app](https://play.google.com/store/apps/details?id=sh.spike.spike_sh_app) from the Play Store. {% endtab %} {% endtabs %} ## Setup To receive mobile alerts, add phone notifications to your escalation policies. Spike will then deliver alerts directly to your device. ## Critical alerts Critical alerts reach you even when your device is on Do Not Disturb. ### iOS Spike supports Apple's critical notifications. Configure this in the app settings to apply to critical incidents only, or all incidents. {% hint style="info" %} Critical notifications make sound even when your iPhone is on mute. {% endhint %} ### Android Spike supports Android's critical notifications. Configure this in the app settings to apply to critical incidents only, or all incidents. {% hint style="info" %} Critical notifications make sound even when your Android device is on mute. {% endhint %} # Email alerts Spike sends detailed email alerts for incidents, including incident details, stack trace, and a shareable public link. In your escalation policy, select the **Email** option and choose the team member who should receive it.

{% hint style="info" %} Spike sends emails from and . To make sure alerts land in your inbox, add these addresses as contacts or download the vCard below. {% endhint %} {% content-ref url="/pages/-MBhMEdIfiXSznT13ayz" %} [Our notification numbers](/administration/our-notification-numbers) {% endcontent-ref %} # Slack The Spike app for Slack sends incident and on-call alerts to your channels, lets you run incident actions without leaving Slack, unfurls incident links, and answers @Spike mentions with an AI assistan

## Overview The Spike app for Slack delivers incident and on-call alerts to the channels you choose and lets responders act on them in place: acknowledge, resolve, add notes, spin up an incident channel, pull the activity log, inspect the full payload, and open a linked Statuspage incident. It unfurls Spike incident links into an editable preview and includes `@Spike`, an AI assistant that declares incidents, manages responders and on-call overrides, and answers questions about your account from a mention. This page covers: * [Install and connect](#install-and-connect) * [Reconnecting an existing workspace](#reconnecting-an-existing-workspace) * [Incident alerts in Slack](#incident-alerts-in-slack) * [On-call alerts in Slack](#on-call-alerts-in-slack) * [Link unfurling](#link-unfurling) * [@Spike, the AI assistant](#spike-the-ai-assistant) *** ## Install and connect Install the app once per Slack workspace. You need admin access to your Spike account and permission to add apps to your Slack workspace. {% stepper %} {% step %} ### Start from the dashboard Go to **Integrations** in the Spike dashboard and click **Add to Slack**. Starting from the dashboard links the workspace to your Spike account; installing from the Slack marketplace alone does not make that link. {% endstep %} {% step %} ### Authorize in Slack Slack shows the permission screen with the scopes the app requests (listed below) and asks you to pick the workspace to install into. Review and click **Allow**. {% endstep %} {% step %} ### Land back in Spike After authorization you return to **Integrations**, where the workspace now shows as connected. You can then select channels for on-call alerts and add Slack as a step in your [escalation policies](https://app.spike.sh/escalations) to route incident alerts. {% endstep %} {% endstepper %} Anyone on your team can link their personal Slack account to the app by sending the Spike bot a direct message and following the prompt. A linked account is what lets Spike attribute actions to a person and show them private channels they belong to. ### OAuth scopes requested The app requests the following scopes. Each maps to a specific capability; the app does not use scopes beyond what these features need. | Scope | Used for | | ------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | | `chat:write` | Posting incident and on-call alerts, updating those messages in place, and sending action results. | | `commands` | Receiving interactions from buttons and actions on alert messages. | | `app_mentions:read` | Detecting `@Spike` mentions so the assistant can respond. | | `assistant:write` | Powering the `@Spike` AI assistant experience in threads and channels. | | `channels:read` / `groups:read` | Listing public and private channels so you can pick alert destinations. | | `channels:manage` / `groups:write` | Creating a dedicated incident channel from an alert. | | `channels:history` / `groups:history` | Reading a thread's messages only when you ask `@Spike` to create an incident from that thread, so it can carry the context forward. | | `links:read` / `links:write` | Detecting Spike incident links and rendering the unfurled preview. | | `users:read` / `users:read.email` | Matching Slack users to Spike responders when you link a personal account. | | `im:write` | Sending direct messages, including the personal-account connection flow. | {% hint style="info" %} The app reads a thread's contents only when you explicitly ask `@Spike` to create an incident from that thread. It does not read channel messages otherwise. {% endhint %} *** ## Reconnecting an existing workspace The Slack app was rebuilt and now requests additional scopes. Workspaces installed on the previous app keep working for existing features but must reconnect before any of the new capabilities become available. **Before you reconnect**, on the old app: * Incident and on-call alerts continue to be delivered to your existing channels. * Acknowledge and resolve on existing alerts continue to work. **Does not work until you reconnect:** * `@Spike`, the AI assistant. * Link unfurling of incident links. * Add a note, create an incident channel, fetch the activity log, view the full payload, and create a Statuspage incident from an alert. * Adding an on-call override directly from an on-call alert. ### Steps to reconnect {% stepper %} {% step %} ### Open Integrations Go to **Integrations** in the Spike dashboard and find your connected Slack workspace. {% endstep %} {% step %} ### Reconnect Click **Reconnect** (or **Add to Slack** again for the same workspace). Slack shows the updated permission screen listing the new scopes. {% endstep %} {% step %} ### Approve the new scopes Confirm the workspace and click **Allow**. The workspace returns to a connected state with the new scopes granted. {% endstep %} {% endstepper %} ### What survives a reconnect | Configuration | Survives? | | ------------------------------------------------------------------ | --------------------- | | Channel mappings (alert destinations) | Yes. Preserved as-is. | | Escalation routing (Slack steps in policies) | Yes. Preserved as-is. | | Notification rules (on-call channel selections and shift settings) | Yes. Preserved as-is. | Reconnecting re-authorizes the existing installation and adds scopes; it does not reset your configuration. {% hint style="warning" %} Reconnecting is not restricted to the original installer. Any Spike admin with permission to add apps to the Slack workspace can reconnect. The person who reconnects becomes the current authorizing user for the installation. {% endhint %} *** ## Incident alerts in Slack

Add Slack as a step in an [escalation policy](https://app.spike.sh/escalations) to send incident alerts to a channel. Each alert message shows the incident title, current status, priority and severity, the triggering integration, assigned responders, and a link back to the incident in Spike. Status changes made anywhere — Slack, phone, SMS, email, or the dashboard — update the message in place, so the channel always sees the current state. ### Actions on an alert | Action | What it does | Visible to | Requires | | ---------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------- | ---------------------------------------------------------- | | **Acknowledge** | Marks the incident acknowledged in Spike and stops further escalation. Updates the message for everyone. | Channel | Linked account recommended so the ack is attributed to you | | **Resolve** | Marks the incident resolved in Spike. Updates the message for everyone. If it was already resolved elsewhere, the app tells you. | Channel | Linked account recommended for attribution | | **Add a note** | Opens a dialog to write a note; the note is saved to the incident's timeline in Spike. | Channel | Linked account for attribution | | **Create an incident channel** | Creates a dedicated channel for the incident and posts a link to it on the alert. Only the person who clicked is added initially; others can join. | Channel (the new channel link is posted) | `channels:manage` / `groups:write` | | **Fetch the activity log** | Pulls the incident's activity log from Spike and shows it to you. | Only you (ephemeral) | — | | **View the full incident payload** | Shows the complete raw payload that triggered the incident. | Only you (ephemeral) | — | | **Create a Statuspage incident** | Creates an incident on your connected Statuspage and links it to the Spike incident, so status updates stay associated. | Channel | A connected **Statuspage** integration | {% hint style="info" %} **Create a Statuspage incident** appears only when a Statuspage integration is connected to your Spike account. Without it, the action is not shown. {% endhint %}

Dedicated incident channel in Slack — A dedicated incident channel created from an alert.

{% hint style="info" %} The two read-only actions — **Fetch the activity log** and **View the full incident payload** — reply only to the person who clicked, so large output does not flood the channel. {% endhint %} *** ## On-call alerts in Slack

Go to **Integrations** to choose the channels that receive on-call alerts. Alerts can be sent when a shift starts and when a shift ends. The message names the schedule, who is going on or off call, and the shift window. ### Add an on-call override from the alert The alert includes an **Add override** action so you can arrange short-term coverage without opening the dashboard. * **Fields:** the team member who will cover, and the start and end time of the coverage. An optional comment can be added for context. * **What it writes:** the override is written to the same on-call schedule the alert came from — the exact schedule and rotation, not a separate one. * **How long it lasts:** the override applies only for the start-to-end window you set. It is a one-time, non-recurring adjustment and does not change the underlying schedule. When the window ends, the normal rotation resumes. * **Editing or removing it:** manage it from the [on-call schedule](https://app.spike.sh/on-calls) in the dashboard — open the schedule, find the override, and edit its times or delete it. See [On-call overrides](/oncall-schedules/override-an-on-call) for details. Anyone without a Viewer role can add or delete overrides. *** ## Link unfurling Paste a Spike incident link into a channel and the app renders an inline preview of that incident instead of a plain URL. The preview shows: * Incident title * Status * Priority and severity * Assigned responders * The triggering integration * A link to open the incident in Spike Fields you can edit inline from the preview: * **Status** — acknowledge or resolve the incident. * **Responders** — add or remove people from the incident. Editing from the preview changes the incident in Spike and is reflected everywhere the incident appears. {% hint style="warning" %} Unfurling requires the app to be present in the channel where the link is pasted. In a channel the app has not been added to, the link stays a plain URL. Add the app with `/invite @Spike` in that channel. {% endhint %} *** ## @Spike, the AI assistant `@Spike` responds to mentions in channels and threads. Mention it in plain language to run incident and on-call actions or ask about your account. ### What it can do | Capability | Example invocation | Expected reply | | ------------------------------------------ | ---------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | Declare a new incident | `@Spike declare a new incident: checkout returning 500s` | Creates the incident in Spike and replies with a link and its status. | | Create an incident from the current thread | `@Spike turn this thread into an incident` | Reads the thread, creates an incident that carries the thread's context into the description, and replies with a link. | | Add responders | `@Spike add @maya and @chen to INC-1043` | Adds those users as responders and confirms who was added. | | Remove responders | `@Spike remove @chen from INC-1043` | Removes the responder and confirms. | | Add an on-call override | `@Spike put @maya on call for payments from 6pm to 10pm` | Writes a one-time override to that schedule for the window and confirms the coverage. | | Show who is on call | `@Spike who's on call for payments right now?` | Replies with the current on-call responder(s) for the schedule. | | List open incidents | `@Spike list open incidents` | Replies with the current open incidents and their status. | | Answer questions about the account | `@Spike which escalation policy does the API service use?` | Answers from your Spike account data. | ### Boundaries * **What it cannot do:** `@Spike` does not delete incidents or schedules, change billing, alter account settings, or take destructive actions. It acts within the same permissions your Spike account exposes and asks for clarification when a request is ambiguous. * **Scope of an action:** an action applies to the incident named in the request. It does not act on unrelated incidents or on incidents it was not mentioned about, and it does not take action on its own without a mention. * **Whose permissions apply:** an action runs under the permissions of the person who invoked it — the linked Spike user who sent the mention — not the app installer. If that person is not linked or lacks permission for the action, `@Spike` declines and says so. Link your account by sending the Spike bot a direct message. * **Activity log and attribution:** actions `@Spike` takes are recorded in the incident's activity log like any other action, and are attributed to the person who invoked them, noted as performed via `@Spike`. ### Availability `@Spike` is available in every workspace running the current app. It becomes active once the workspace has been installed — or [reconnected](#reconnecting-an-existing-workspace) — with the current scopes; workspaces still on the previous app must reconnect before `@Spike` will respond. *** ## FAQs ### Do I have to reconnect if everything still works? Alerts and acknowledge/resolve keep working on the old app, but the new actions, unfurling, and `@Spike` stay off until you [reconnect](#reconnecting-an-existing-workspace). ### I can't find a channel in the dropdown. What should I do? Paste the channel ID. Open the channel in Slack, go to the **About** section, and copy the unique ID.

Finding a Slack channel ID — Find the channel ID in the About section.

### Why can't I see a private channel when picking a destination? You must be a member of the private channel, have a linked Slack account, and have added the app to that channel with `/invite @Spike`. Private channel names are visible only to linked members of that channel. ### Can non-Spike users use `@Spike` or join an incident channel? Anyone in the workspace can be invited to an incident channel. For `@Spike` actions that change data, the person must have a linked Spike account with sufficient permission; otherwise `@Spike` declines. ### Can the same incident channel be reused for another incident? No. A new channel is created per incident. Archive it after the incident is resolved to keep your workspace tidy. ### Does Spike read our messages? No. The app reads a thread's contents only when you explicitly ask `@Spike` to create an incident from that thread. It does not otherwise read channel messages. # Microsoft Teams The Spike app for Microsoft Teams sends incident alerts to your channels. Acknowledge, resolve, or escalate incidents directly from Teams. The Spike app for Microsoft Teams delivers incident alerts to your channels and on-call notifications to your DMs. Key features: * Real-time incident alerts in Teams channels * Acknowledge, resolve, or escalate incidents from Teams * Create incidents directly from Teams * On-call shift notifications via DMs * Check who is currently on-call [Install the Teams app](https://teams.microsoft.com/l/app/aea2c271-cfd3-4360-86bb-4a16998b2bde?source=app-details-dialog) directly or search for "Spike" in the Teams Apps section. Contact your Teams admin if you need help with installation due to permission restrictions. {% embed url="" %} ## Getting started After installing the app, you'll receive a message with instructions on how to connect your Spike account. Run both the `connect` and `connect-org` commands for full functionality. {% hint style="info" %} * The `connect` command links your personal Spike account with Teams, enabling direct messages for on-call shift notifications and comment mentions. * The `connect-org` command links your organisation's Spike account with Teams, enabling incident alerts in channels. Run both commands for the best experience. {% endhint %} ## Available commands {% tabs %} {% tab title="Commands in Microsoft Teams" %} * **New incident** (`/create-new-incident`): Create a new incident from Teams. * **Am I on-call?** (`/oncall-me`): Check if you are on-call and when your shift ends. * **Who is on-call?** (`/oncall-now`): See who is currently on-call. * **Disconnect** (`/disconnect`): Disconnects your personal Spike account from Teams. Incident alerts in channels continue. {% endtab %} {% endtabs %} ## Setting up incident alerts Once connected, add any Teams channel to an escalation policy. Select **Teams** in the escalation policy and your available channels appear on the right.

Incident alerts on Microsoft Teams — Incident alerts in a Teams channel.

Any team member can take action on an incident directly from Teams. Creating a dedicated channel for responders is a good practice. If an incident is acknowledged or resolved via the Spike dashboard, phone, email, or any other channel, the Teams message updates automatically with the latest status, including suppressed and repeat counts. ## Direct messages

Direct messages from Spike on Microsoft Teams — Direct messages from Spike in Teams.

After running the `connect` command, Spike sends direct messages for: 1. War room invites 2. Comment mentions 3. On-call shift alerts Use `/oncall-me` and `/oncall-now` to check on-call schedules directly in Teams. ## Connecting multiple groups The Spike bot connects to multiple groups of channels in Teams. This is useful for organisations with several teams. ### How to connect 1. In Teams, go to the channel of the group you want to connect. 2. Type `@Spike.sh connect-org` to connect with Spike. There is no limit on how many groups can be connected. ### After connecting * Visit your [Escalation Policies](https://app.spike.sh/escalations) and add the desired channel to receive alerts. * The newly connected Teams channels appear in the dropdown. ### Finding channels in escalations Teams shows the group name only alongside the first channel from each group. The first channel appears as "standard" instead of the actual channel name. Other channels from the same group don't show the group name. This can cause confusion if you have similarly named channels across different groups.

Naming convention for Microsoft Teams channels in escalations — How Teams channel names appear in escalation policies.

For example: * **Spike.sh - standard**: the first channel in the "Spike.sh" group, even if the channel's actual name is different * **Engineering**: another channel in the same group, shown without the group name * **Developer space - standard**: the first channel in "Developer space"; actual name is "dev space" * **Incidents**: another channel in the same group, shown without the group name ## Deprecated: incoming webhook {% hint style="warning" %} Microsoft deprecated all new webhook connectors on 15th September 2024. Spike deprecated incoming webhook support on 26th November 2024. {% endhint %}

Incident alert via incoming webhook on Teams — Incident alert via the deprecated incoming webhook method.

# WhatsApp Get incident alerts and on-call shift notifications on WhatsApp. Acknowledge or resolve incidents without leaving WhatsApp. You can receive alerts for: * New incidents * Acknowledge timeout * On-call shift start * On-call shift end

## How to set up WhatsApp is enabled by default for all phone numbers. Add it to your escalation policies or configure on-call notifications in [On-call settings](https://app.spike.sh/settings/personal-on-call).

WhatsApp in an escalation policy — Adding WhatsApp to an escalation policy.

{% hint style="success" %} To acknowledge or resolve an incident, reply to the Spike WhatsApp bot with `ack test-123` or `res test-123`, where `test-123` is the incident ID. {% endhint %} If you prefer a different messaging bot, Spike also has a Telegram integration: {% content-ref url="/pages/Gb7bmAayc9oQ7nvFiRBf" %} [Telegram](/alerts/telegram) {% endcontent-ref %} # Telegram Get incident alerts and on-call shift notifications on Telegram. Acknowledge or resolve incidents with a simple command. Spike's Telegram bot is [@SpikeHQ\_bot](https://t.me/SpikeHQ_bot). Run `/connect` to link your Spike account and start receiving alerts. You can receive alerts for: * New incidents * On-call shift start * On-call shift end

Incident alert on Telegram from Spike — Incident alert on Telegram.

Add Telegram to your [escalation policies](https://app.spike.sh/escalations) to receive incident alerts. For on-call shift alerts, visit [On-call settings](https://app.spike.sh/settings/personal-on-call). {% hint style="success" %} Use `/ack` or `/acknowledge` to acknowledge an incident. Use `/res` or `/resolve` to resolve one. {% endhint %} {% hint style="info" %} Telegram can only be connected to one Spike account at a time. {% endhint %} # Discord Set up Spike's webhook integration to send incident and on-call alerts directly to your team's Discord channels.

Incident alert on Discord from Spike — Incident alert on Discord.

## How to set up {% stepper %} {% step %} ### Create a webhook in Discord Navigate to your channel's **Settings** > **Integrations** and select **Webhooks**.

{% endstep %} {% step %} ### Name and copy the webhook URL Name the webhook **Spike** and copy the URL. You can use the badge below as the avatar. {% file src="/files/-MaByxWw7T3nNKjWl5bJ" %} Spike badge for Discord {% endfile %}

Naming the webhook and copying the URL — Name the webhook and copy the URL.

{% endstep %} {% step %} ### Paste the URL in Spike Go to **Integrations**, paste the webhook URL in the Discord setup, and save.

Saving the Discord webhook URL in Spike — Paste the webhook URL in Spike integrations.

{% hint style="success" %} Once saved, Spike sends a test message to your Discord channel. {% endhint %} {% endstep %} {% step %} ### Add Discord to your escalation policy Select Discord as a step in your [escalation policy](https://app.spike.sh/escalations).

Discord as a step in an escalation policy — Adding Discord to an escalation policy.

{% endstep %} {% endstepper %} ## Remove a Discord channel You can remove a Discord channel from Spike, but make sure it's not part of any active escalation policy before doing so. {% hint style="info" %} Discord doesn't support acknowledging or resolving incidents from the channel. Use the Spike dashboard, phone, SMS, or other alert channels to take action. {% endhint %} # Alert routing rules Alert routing rules apply automated actions to every incoming incident based on conditions you define with AND/OR logic. Alert routing rules evaluate conditions on every incoming incident and execute actions when those conditions are met. You can chain multiple conditions with AND/OR logic and apply multiple rulesets to a single incident.

Example alert routing rule in Spike — An example alert routing rule with conditions and actions.

{% hint style="info" %} Not sure where to start? Spike offers [alert routing rule templates](https://spike.sh/templates/alert-rule-templates) with pre-built configurations. {% endhint %} ## Conditions Each condition evaluates to true or false. If any condition block evaluates to true, Spike executes the configured actions. ### Apply to all incidents Evaluates to true for every incident. Use this when an action should run unconditionally. ### Incident title Evaluates to true if the incident title contains, does not contain, equals, or does not equal a specific text or phrase. ### Incident details Evaluates to true if a specific key in the incident details contains, does not contain, equals, or does not equal a specific value. Enter a key or nested key to compare against. ### Incident has repeated Evaluates to true if the total number of incident occurrences crosses a threshold you set. ### Incident has repeated within Evaluates to true if incident occurrences cross a threshold within a given timeframe. ### Incident suppressed Evaluates to true if the incident has been suppressed at least a minimum number of times. ### Incident suppressed within Evaluates to true if the incident has been suppressed at least a minimum number of times within a given timeframe. ### Priority Evaluates to true if the incident has a given priority. [Learn more about priority](https://docs.spike.sh/incidents/priority-and-severity#priority) ### Severity Evaluates to true if the incident has a given severity. [Learn more about severity](https://docs.spike.sh/incidents/priority-and-severity#severity) ### Time of day Evaluates to true if the incident triggers between timestamps you set, in any timezone. ### Days of week Evaluates to true if the incident triggers on specific days of the week. ## Actions Set one or more actions to execute when conditions are met. ### Reassign incident to Assigns the incident to a team member. An email notification is sent to the assignee. ### Load escalation policy Replaces the default escalation policy with one you specify. Useful for routing high-severity incidents to a more comprehensive policy. ### Change integration Routes the incident to a different integration based on conditions you define. Use this to automatically move incidents to the right integration and team without manual intervention. For example, an incident arrives under the API integration. If the title contains "payments", Spike moves it to the Payments integration and alerts the payments team instead. Pair this with the **Incident suppressed** or **Incident suppressed within** conditions to switch integrations when an incident is being suppressed too frequently. ### Ignore incident Prevents the incident from being created. No alerts are sent and the incident doesn't appear on the dashboard. ### Mark priority as Sets the incident's priority. [Learn more about priority](https://docs.spike.sh/incidents/priority-and-severity#priority) ### Mark severity as Sets the incident's severity. [Learn more about severity](https://docs.spike.sh/incidents/priority-and-severity#severity) ### Trigger outbound webhook Sends a webhook to a URL you specify when the conditions are met. ### Acknowledge incident Creates the incident in the acknowledged state. No alerts are sent, but the incident appears as open on the dashboard. ### Resolve incident Creates the incident in the resolved state. No alerts are sent and the incident doesn't appear as open on the dashboard. ### Resolve by Timer Automatically resolves the incident after a set duration. [Learn more about Resolve by Timer](https://github.com/spikehq/docs.spike.sh/tree/main/alerts/resolve-timer.md) ## Route to other team Enable the **Route to other team** toggle in the Actions section to send an incident from one team to another. Select the source team, destination team, and destination integration. ## Applying multiple rulesets Multiple alert routing rulesets can apply to a single incident. For example:

Alert routing ruleset example — Ruleset 1: mark as P5 if title contains "syslog".

If an incident title contains "syslog", both rulesets apply: the incident is marked P5 and the escalation policy changes to Slack dev. {% hint style="info" %} No more than 5 alert routing rulesets apply to a single incident. {% endhint %} # Title Remapper Title Remapper programmatically rewrites incident titles in real-time using payload data from your integrations. Title Remapper programmatically rewrites incident titles using HandlebarsJS templates and the payload your integration sends. Use it to add context like a project name or environment, so responders immediately understand what's happening. **Without Title Remapper** ``` var temp is not defined ``` **With Title Remapper** ``` var temp is not defined for Notification service ``` ## How to set up {% stepper %} {% step %} ### Create a new remapper Go to **Automation** > **Title Remapper** and create a new remapper.

Title Remapper in Automation menu — Title Remapper is under Automation in the sidebar.

{% endstep %} {% step %} ### Name your remapper Provide a name for the remapper.

Naming the Title Remapper — Name your remapper.

{% endstep %} {% step %} ### Select an integration Choose the integration whose payload you want to parse.

Selecting an integration for Title Remapper — Select an integration to see its payload.

Spike displays the integration's JSON payload in the preview section. Write your HandlebarsJS parser in the code editor on the left. Press **Try Now** to test the output, then hit **Save**. {% hint style="danger" %} Avoid `#each`, `#unless`, and any other loop constructs in your parser. {% endhint %} {% endstep %} {% endstepper %} ## Caveats 1. One Title Remapper can be linked to multiple integrations. 2. Link a remapper only to integrations it was built for. Linking a remapper built for AWS to a non-AWS integration can cause errors and missing titles. 3. If multiple Title Remappers are linked to the same integration, only the last linked remapper applies. ## Examples All below examples use this payload: ```json data: { "body": { "event_definition_id": "this-is-a-test-notification", "event_definition_type": "test-dummy-v1", "event_definition_title": "Event Definition Test Title", "event_definition_description": "Event Definition Test Description", "job_definition_id": "163", "job_trigger_id": "8999", "event": { "id": "NotificationTestId", "event_definition_type": "notification-test-v1", "event_definition_id": "EventDefinitionTestId", "origin_context": "urn:graylog:message:es:testIndex_42:b5etest--id-4-90ed-0dbeefbaz", "timestamp": "2021-05-05T09:42:42.823Z", "timestamp_processing": "2021-05-05T09:42:42.823Z", "timerange_start": null, "timerange_end": null, "streams": [ "802109582109518290" ], "source_streams": [], "message": "Notification test message triggered from user ", "source": "12837126856181276589235717181276589235716", "key_tuple": [ "testkey" ], "key": "testkey", "priority": 2, "alert": true, "fields": { "field1": "value1", "field2": "value2" } }, "backlog": [] }, "message": "Notification test message triggered from user " } ``` ### Basic **Just the message** ``` {{data.message}} ``` Output: `Notification test message triggered from user ` **Get event title** ``` {{data.body.event_definition_title}} ``` Output: `Event Definition Test Title` **Get more details about the event** ``` [{{data.body.event_definition_type}}] has incident => {{data.body.event_definition_title}} ``` Output: `[test-dummy-v1] has incident => Event Definition Test Title` ### Advanced Use built-in HandlebarsJS helpers or the additional helpers from Spike's [Swag fork](https://github.com/spikehq/swag). **Conditional title** ``` {{#if data.body.event_definition_desc}} Title: {{data.body.event_definition_title}} {{else if data.body.event.message}} Message: [{{data.body.event.key}}] - {{data.body.event.message}} {{else}} {{data.message}} {{/if}} ``` Output: `Message: [testkey] - Notification test message triggered from user ` **Swag helpers** ``` {{uppercase data.message}} with priority {{add data.body.event.priority 1}} ``` Output: `NOTIFICATION TEST MESSAGE TRIGGERED FROM USER with priority 3` Visit the [Swag GitHub repo](https://github.com/spikehq/swag) for more examples. # Personal alerts management Manage how, when, and where you receive incident alerts in Spike to suit your schedule and reduce alert fatigue. Spike gives you full control over your personal alert preferences. Configure how alerts reach you during office hours, outside office hours, and when you're away. For example, when you're out of office, you can configure Spike to stop sending alerts. You can also reassign responsibilities to another team member when you're off duty. ## Example configurations * **During office hours**: Route all phone call alerts to app notifications. * **Outside office hours**: Prefer receiving alerts via SMS, WhatsApp, or Telegram. * **Out of office**: Forward all alerts to another team member. ## Explore


Resolved incident alerts	Alerts when incidents are resolved	Resolved incident alerts	thumbnail-resolved-alerts.png
During office hours	Custom routing of alerts during office hours	During office hours	thumbnail-office-hours.png
Out of office	Step away confidently by scheduling Out of office	Out of office	thumbnail-out-of-office.png

# During office hours Customize how Spike routes your alerts during office hours — by SMS, mobile app, or another channel that fits your workflow.

Alerts during office hours settings in Spike — Configure alert preferences for office hours.

## Alerts during office hours Customize how you receive alerts during office hours, whether for incident triggers or resolutions. If you’re working at your desk, you might prefer to route all SMS alerts to the [mobile app](/alerts/mobile-app-alerts) for better accessibility. Field engineers may prefer to continue receiving alerts via [SMS](/alerts/sms). {% hint style="info" %} On-call shift start/end alerts remain unaffected. If an incident occurs during your on-call shift within office hours, alerts will be sent according to your configured settings. {% endhint %} #### Set up {% tabs %} {% tab title="Mobile app" %} * Go to `Settings` * Tap on `Alerts during office hours` * Configure your alert preferences and tap `Save` {% endtab %} {% tab title="Desktop" %} * Navigate to `Your account settings`([Dashboard link](https://app.spike.sh/settings/personal-modes#office-mode-alerts)) * Click `Modes` * Configure your alert preferences and click `Save` {% endtab %} {% endtabs %} ### Setting office hours By default, your office hours are set to Monday through Friday, 9 AM to 5 PM in your local timezone ([found on profile page](https://app.spike.sh/settings/personal-profile)). You can customize these hours to fit your schedule, including different days and times. #### Set up {% tabs %} {% tab title="Mobile app" %} * Go to `Settings` * Tap on `Office hours` * Select your preferred days and times {% endtab %} {% tab title="Desktop" %} * Navigate to `Your account settings` ([Dashboard link](https://app.spike.sh/settings/personal-modes)) * Click `Modes` * Select your times and click `Save` {% endtab %} {% endtabs %} **Download Spike mobile app** * [iOS](https://apps.apple.com/au/app/spike-sh/id1586777789) * [Android](https://play.google.com/store/apps/details?id=sh.spike.spike_sh_app) #### Explore


Resolved incident alerts	Alerts when incidents are resolved	Resolved incident alerts	thumbnail-resolved-alerts.png
Out of office	Step away confidently by scheduling Out of office	Out of office	thumbnail-out-of-office.png

# Out of office Set up Out of Office mode to temporarily pause alerts, schedule time off, and seamlessly offload duties to team members.

Out of office mode in Spike — Schedule Out of office and offload duties to a teammate.

## Out of office Heading out of the office? You can schedule or instantly set up **Out of Office**, so your duties including on-call responsibilities and incident alerts are covered by a colleague. Out of Office mode is designed to support better work-life balance. **While you're away, Spike will not send you any alerts**. You can even schedule this ahead of time, and an email will be sent to the admins in your organization, keeping everyone informed. ### Offloading Duties When setting up Out of Office, you can offload your responsibilities to a selected team member. Spike takes care of everything automatically—there’s no need to manually move members in the on-call schedule or add overrides. Your on-call shifts and incident alerts will be temporarily rerouted to the designated member. {% hint style="info" %} Although optional, we recommend offloading your duties to make sure incidents are addressed in your absence and you are not disturbed. {% endhint %} #### Set up {% tabs %} {% tab title="From settings on Desktop" %} * Navigate to `Your account settings` ([Dashboard link](https://app.spike.sh/settings/personal-modes#vacation-mode)) * Click `Modes` * Scroll down to **Out of office** * Add **Starts on** and **Ends on**, then click `save` *Optionally, select a member to offload duties* {% endtab %} {% tab title="From the header on Desktop" %} * From the header, click `Select a mode` * Select **Out of office** from the dropdown * Add **Starts on** and **Ends on**, then click `save` *Optionally, select a member to offload duties* {% endtab %} {% endtabs %} #### Explore


Resolved incident alerts	Alerts when incidents are resolved	Resolved incident alerts	thumbnail-resolved-alerts.png
During office hours	Custom routing of alerts during office hours	During office hours	thumbnail-office-hours.png

# Resolved incident alerts Customize how and when you receive notifications for resolved incidents, keeping you informed without unnecessary alerts.

Resolved incident alerts configuration in Spike — Configure how you receive resolved incident alerts.

## Resolved incident alerts Spike notifies you when incidents are automatically resolved or resolved by a responder. This helps provide closure and peace of mind, ensuring you’re informed that an incident you were alerted to has been resolved. It completes the alert cycle effectively. By default, only current responders and members who were alerted when the incident was triggered will receive a resolved incident alert. You can customize how you receive resolved incident alerts, including different mediums during office hours. {% hint style="info" %} The Spike mobile app is ideal for instant notifications when incidents are resolved. {% endhint %} #### Set up {% tabs %} {% tab title="Mobile app" %} * Go to `Settings` * Tap on `Resolved alerts` * Configure your alerts **Download Spike mobile app** * [iOS](https://apps.apple.com/au/app/spike-sh/id1586777789) * [Android](https://play.google.com/store/apps/details?id=sh.spike.spike_sh_app) {% endtab %} {% tab title="Desktop" %} * Navigate to `Your account settings` ([Dashboard link](https://app.spike.sh/settings/personal-modes#resolved-alerts)) * Scroll down to `Resolved alerts` * Congiure your alerts and click `Save` {% endtab %} {% endtabs %} ### FAQs

Can I get notifications for all incidents?

No, by design, Spike only alerts current responders and members who were previously notified of the incident. This prevents alert fatigue and ensures that those who were not involved are not disturbed unnecessarily.

Will I receive another alert on Slack, Microsoft Teams, or Discord?

**Slack and Microsoft Teams:** There will be no new alert, but the original alert message in your Slack or Teams channels will automatically refresh to indicate the resolved status. **Discord:** No additional alert will be sent.

Why can't I receive a phone call for a resolved incident alert?

Resolved incident alerts are important, but not critical enough to wake you in the middle of the night with a phone call. This avoids confusion—when you receive a phone call from Spike, it will always be for a newly triggered incident, so there’s no need to guess whether it’s for a new or resolved alert.

*** #### Explore


During office hours	Custom routing of alerts during office hours	During office hours	thumbnail-office-hours.png
Out of office	Step away confidently by scheduling Out of office	Out of office	thumbnail-out-of-office.png

# Introduction to services Services scope your infrastructure in Spike. Each service can hold multiple integrations and map to a microservice, product area, or team. A service in Spike represents a distinct part of your infrastructure — a backend API, a payments module, a worker queue. Every integration belongs to a service, and every incident is tied to one. ## Why services matter Services give you a clean way to track incidents by area. When something breaks, you can see exactly which service is involved, who owns it, and what's happening across your stack. ## Affected services When an incident is triggered, its service is marked as affected. If multiple integrations fire at once, Spike surfaces all the involved services in one view — so responders know where to focus. ## Create a service

{% content-ref url="/pages/-Ln3rb4wLUFeI-OAPcmq" %} [Create integration and service on our dashboard](/integrations-guideline/create-integration-and-service-on-dashboard) {% endcontent-ref %} # Escalation policies Escalation policies define who gets alerted, through which channel, and in what order, until an incident is acknowledged. An escalation policy defines who gets alerted, through which channel, and in what order. When an incident triggers, Spike follows the policy until someone acknowledges or resolves it.

Escalation policies list in Spike — Escalation policies in Spike.

## How escalation policies work Each policy has one or more levels. After Spike sends alerts at the first level, it waits for a configured timeout before moving to the next. If no one acknowledges within that window, the incident escalates to the next level automatically. You can alert multiple people at the same level, across different channels or the same one. You can configure the timeout between levels and create as many levels as you need.

Escalation policy with two levels in Spike — An escalation policy with two levels and a 5-minute timeout.

{% hint style="info" %} Escalations don't repeat automatically. Configure repeat escalations in your integration settings. [Learn more](/escalations/repeat-escalations) {% endhint %} {% hint style="info" %} You can create unlimited escalation policies with multiple levels. {% endhint %} # How to create an escalation policy Step-by-step guide to creating an escalation policy in Spike to define who gets alerted, and when, during an incident. {% hint style="info" %} Not sure where to start? Spike offers [escalation policy templates](https://spike.sh/templates/escalation-templates) with pre-built configurations. {% endhint %} {% stepper %} {% step %} ### Go to Escalations Navigate to the [Escalations section](https://app.spike.sh/escalations) on the dashboard and click **New escalation**.

Escalations section on the Spike dashboard — Select Escalations from the sidebar.

{% endstep %} {% step %} ### Configure the policy 1. Give the policy a clear, identifiable name. 2. Add one or more escalation levels. 3. Set a timeout for each level. This is how long Spike waits before escalating to the next level if the incident isn't acknowledged or resolved.

An example escalation policy in Spike — An example escalation policy with two levels.

{% hint style="info" %} Leave the time interval blank on the last escalation step. {% endhint %} {% endstep %} {% step %} ### Save Click **Save** to activate the policy. {% endstep %} {% endstepper %} ## Simultaneous alerts To alert multiple people or channels at the same time, add them as separate alerts within the same escalation level. Avoid creating a new escalation level with a 0-minute interval. This is not the same as simultaneous alerting.

Correct: multiple alerts within the same escalation level — Correct: multiple alerts within one escalation level.

# Repeat escalations Repeat escalations restart the escalation policy from the top when no one has acknowledged or resolved the incident. When all escalation levels are exhausted and no one has taken action, repeat escalations restart the policy from the top. Spike repeats the cycle until someone acknowledges or resolves the incident, or the repeat limit is reached. ## How it works Consider this escalation policy: 1. Alert on #on-call-alerts Slack channel 2. Email Alex James 3. Phone call to Alex James

Example escalation policy in Spike — An example escalation policy with three levels.

If no one on the Slack channel takes action and Alex doesn't respond, Spike restarts from Step 1 after a default interval of 10 minutes. {% hint style="info" %} Escalations repeat a maximum of 5 times to prevent alert fatigue. {% endhint %} ## How to set up Repeat escalations are configured per integration, not globally. This gives you control over which integrations are critical enough to never miss. Configure it while adding or editing an integration. Select the **Repeat escalation** checkbox and save.

Configure repeat escalations for an integration — Enable repeat escalations on an integration.

## FAQs ### What stops repeat escalations? Acknowledging or resolving the incident stops the repeat cycle. Alerts stop automatically once either action is taken. {% content-ref url="/pages/-Ln7Jxx-MbPRgKiIKLTu" %} [How to change incident status](/incidents/how-to-change-incident-status) {% endcontent-ref %} ### How many times do escalations repeat? By default, escalations repeat up to 5 times. After that, no further alerts are sent. # Archive escalation policy Archive an escalation policy in Spike once it's no longer associated with any integration, from the policy settings. You can archive an escalation policy when it's no longer associated with any integration. Visit your [escalations page](https://app.spike.sh/escalations), select a policy, click the settings icon, and select **Archive**.

Archive option under escalation policy settings — Select Archive under the policy settings.

## Restrictions If the policy is in use on one or more integrations, archiving is not available. Update those integrations to use a different escalation policy first. {% hint style="success" %} Once the policy is no longer associated with any integration, you can archive it. {% endhint %} ## FAQs ### Does archiving affect on-call schedules? No. Archiving an escalation policy does not affect on-call schedules. ### Does archiving affect existing incidents? No. Existing incidents retain a reference to the archived policy. Spike displays a notice on those incidents to flag that the policy has been archived. ### How do I restore an archived policy? There's no self-serve restore option. Contact support via chat from the dashboard or email . # Task management integrations Create tickets, tasks, or issues in your project management tool — Jira, Linear, ClickUp, or Shortcut — directly from Spike incidents.


Linear	Connect with Linear to create issues about incidents	Linear card cover (2).png	Linear
Jira	Supports Jira cloud to create tickets about incidents	Jira card cover.png	JIRA Cloud
Shortcut	Shortcut connect enables creating tickets with all incident details	Shortcut card cover.png	Shortcut
ClickUp	ClickUp connection helps add incidents to your workspace	ClickUp card cover.png	ClickUp
Jira (self-hosted)	Create tickets from incidents on self-hosted Jira	Jira (self-hosted) card cover.png	JIRA server (self-hosted)

Some incidents need more than an immediate fix. Task management integrations let you create tickets directly from Spike incidents for follow-up work like root cause analysis or longer-term planning. ## FAQs ### Who can create tickets from incidents? Anyone on your team can create tickets from incidents. Access is not restricted to admins. ### Are these integrations bi-directional? No. Spike sends incident data to your project management tool. Updates made in that tool don't sync back to Spike. ### Privacy Spike doesn't read data from your project management platform, including user, task, or project info. Spike only sends incident data. {% hint style="info" %} More integrations are planned. Email to request one. {% endhint %} # JIRA Cloud Connect Jira Cloud to Spike to create Jira tickets directly from incidents for tracking longer-term follow-up work. ## How to set up Go to [Integrations](https://app.spike.sh/integrations) and find the **Jira Cloud** integration. Click **Connect** to authenticate with Jira and grant Spike permission to create tickets.

Jira Cloud setup in Spike — Jira Cloud setup in Integrations.

{% hint style="info" %} Once set up, every team member in your account can create Jira tickets from Spike. {% endhint %} ## How to create a ticket Open the incident details page and use the actions section to create a Jira ticket.

Create a Jira ticket from the incident details page — Use the actions section on the incident page to create a ticket.

Fill in the required details and submit.

Fill in ticket details to create a Jira ticket from Spike — Fill in the details to create a ticket on Jira.

# JIRA server (self-hosted) Connect Spike to a self-hosted Jira server using OAuth credentials to create tickets directly from your incidents. To connect, you need three things from your Jira server: * **Base URL** (the domain where your server is hosted, e.g. `https://jira.mydomain.com`) * **Client ID** * **Client Secret** ## Generate credentials on Jira 1. On your Jira server, go to **Settings > Applications** 2. Click **Application Links** 3. Click **Create Link**

Application Links in Jira server settings.

4. On the Create Link modal, select **External application** and **Incoming**

Create Link modal in Jira — Select External application and Incoming.

5. Fill in the details: * **Name**: Spike * **Callback URL**: `https://app.spike.sh/task-management/jira/self-hosted/auth/callback` * **Permission**: Write * Click **Save**

Jira application link details form — Fill in the application link details.

6. Copy the generated **Client ID** and **Client Secret** 7. Your **Base URL** is the domain where Jira is hosted, e.g. `https://jira.spike.sh`. Do not include a trailing slash.

Generated Client ID and Client Secret in Jira — Copy the Client ID and Client Secret.

## Connect in Spike Go to [Settings > Organisation](https://app.spike.sh/settings/general/organisation#org--task-management) and select **JIRA server**. Enter the Base URL, Client ID, and Client Secret. Then click **Connect**.

Jira server connection form in Spike settings — Enter your Jira server credentials in Spike settings.

Jira opens for validation. Grant the requested permissions to complete the connection. # ClickUp Connect ClickUp to Spike to create tasks directly from incidents, so follow-up work is tracked without leaving Spike. ## How to set up Go to [Integrations](https://app.spike.sh/integrations) and find the **ClickUp** integration. Click **Connect** to authenticate with ClickUp and grant Spike permission to create tasks.

ClickUp setup in Spike — ClickUp setup in Integrations.

{% hint style="info" %} Once set up, every team member in your account can create ClickUp tasks from Spike. {% endhint %} ## How to create a task Open the incident details page and use the actions section to create a ClickUp task.

Create a ClickUp task from the incident details page — Use the actions section on the incident page to create a task on ClickUp.

ClickUp task creation form in Spike — Fill in the details and create the task.

# Linear Connect Linear to Spike and create issues directly from incidents. Acknowledgment, resolution, and comments stay in sync across both platforms.

## Linear Spike's Linear integration bridges incident response with task tracking. Create an issue from any incident and both platforms stay updated as it moves through resolution. The integration supports three main capabilities: * Sync incident status with Linear issue status * Sync comments between both platforms * Create issues manually or automatically ### How it works When an incident triggers in Spike, it can appear as an issue in Linear. Your team can track and work on it in Linear while Spike stays updated. Status changes sync in both directions. When an issue is marked "Done" in Linear, Spike resolves the corresponding incident. When an issue moves to "In Progress," Spike acknowledges it. Comments sync too. A comment on Linear appears in Spike as "Linear commented." A comment on Spike appears in Linear as "Spike commented." {% hint style="info" %} Reverting an issue's status in Linear won't update the incident in Spike. If an issue moves from "Done" back to "In Progress" on Linear, the resolved incident stays resolved. Resolved incidents are terminal in Spike and cannot be re-opened. If an issue moves from "In Progress" back to "Todo" on Linear, the acknowledged incident stays acknowledged. In Spike, you can manually move an acknowledged incident back to triggered, but Linear's sync does not trigger that change. {% endhint %} ### Set up Go to [Settings > Organisation](https://app.spike.sh/settings/general/organisation) and find the **Task management integrations** section. Click **Connect** next to Linear and complete the authentication. Once set up, all team members in your account can create issues in Linear directly from Spike. {% tabs %} {% tab title="Creating issues on Linear" %} 1. **Manually create issues** Select the incidents, locate the Linear button, and follow the prompts to create an issue.

Manually create a Linear issue from a Spike incident — Create an issue on Linear.

2. **Automate creating issues** With [Playbooks](/playbooks/introduction-to-playbooks), you can pre-configure and automate creating Linear issues. When creating a playbook, select **Create an issue on**, then **Linear**, and complete the setup.

Automate Linear issue creation using Spike Playbooks

{% endtab %} {% tab title="Link existing Linear issue with Spike" %} Link an existing Linear issue to a Spike incident to sync both statuses and comments. Multiple Linear issues can be linked to a single incident. Resolving the incident in Spike marks all associated Linear issues as "Done."

{% endtab %} {% endtabs %} ### FAQs #### What permissions are needed to connect Linear with Spike? You need administrative access to connect Spike with Linear. Once connected, all team members in Spike can create issues in Linear from incidents. #### What happens to comments made on Linear? A comment made on Linear appears in Spike as "Linear commented." A comment made on Spike appears in Linear as "Spike commented." # Shortcut Connect Shortcut to Spike to create stories from incidents, covering follow-up work like root cause analysis fast. Spike's Shortcut integration creates stories from incidents. Stories cover follow-up work like root cause analysis or longer-term fixes that go beyond immediate incident response. ## How to set up Go to [Integrations](https://app.spike.sh/integrations) and find the **Shortcut** integration. Click **Connect** and enter your Shortcut API key. Spike validates the key and completes the connection.

Shortcut setup in Spike Integrations — Shortcut setup in Integrations.

{% hint style="info" %} Once set up, every team member in your account can create stories in Shortcut from Spike. Spike does not read any data from your Shortcut account. {% endhint %} ## How to create a story Open the incident details page and use the actions section to create a Shortcut story.

Create a Shortcut story from the incident details page — Create a story from the incident details page.

You can pre-configure story details before sending to Shortcut.

Pre-configure Shortcut story details in Spike — Pre-configure story details.

## Automate with Playbooks Use [Playbooks](/playbooks/introduction-to-playbooks) to automate creating Shortcut stories. For example, create a story automatically for every new incident with a specific title or on a specific service.

Automate Shortcut story creation with Spike Playbooks — Automate Shortcut stories with Playbooks.

Team members with the right permissions can also run the Playbook manually.

Run a Shortcut Playbook manually in Spike

# Helpdesk integrations Create tickets in Zendesk, Freshdesk, or Supportpal directly from Spike incidents to keep response and support in sync. Spike's helpdesk integrations keep incident response and ticket tracking connected. Create tickets from incidents and sync status, notes, and updates across both platforms.


Zendesk	Bi-directional integration for syncing incidents, notes, and tickets	Zendesk card cover.png	Zendesk
Freshdesk	Send incidents to Freshdesk and add notes	Freshdesk card cover.png	Freshdesk
Supportpal	Sync incidents with Supportpal and keep your teams aligned	Supportpal card cover.png	Supportpal

## Create tickets from incidents Once connected, any team member can create or link helpdesk tickets from incidents: * **From the incidents table**: Select one or more incidents and create a ticket. * **From the incident details page**: Open the incident and create or link a helpdesk ticket directly. ## Automate with Playbooks Use [Playbooks](/playbooks/introduction-to-playbooks) to automate ticket creation whenever an incident triggers. This removes the manual step and ensures every incident gets a corresponding ticket. ## FAQs ### Are these integrations bi-directional? Zendesk and Freshdesk both have a Spike app available in their respective marketplaces. The app allows users on those platforms to check incidents and take action from their helpdesk side. Supportpal is one-way only. Spike sends incident data to Supportpal, but there is no app and no sync back. ### Does Spike access data from my helpdesk platform? Spike does not access or store any data from your helpdesk platform, including tickets or user information. {% hint style="info" %} More integrations are planned. Email to request one. {% endhint %} # Zendesk Connect Zendesk to Spike for bidirectional sync of incidents, tickets, notes, and statuses between both platforms.

## Zendesk Connect Spike with Zendesk for two-way incident and ticket management. Create tickets, sync notes and statuses, and trigger incidents without leaving Zendesk. ### Set up Zendesk can be connected to Spike in two ways. The first is an API connection. Use this to send incidents from Spike to Zendesk and create tickets. The second is the Spike app from the Zendesk Marketplace. This adds full bidirectional sync. Incidents, notes, and statuses flow between both platforms. Zendesk users can also trigger incidents without a Spike account. #### API connection 1. Go to [Settings > General > Helpdesk Integrations](https://app.spike.sh/settings/general/organisation#org--helpdesk-ticket-management) 2. Enter your Zendesk API token and Zendesk subdomain #### Zendesk Marketplace app 1. Install the Spike app from [Zendesk Marketplace](https://www.zendesk.com/in/marketplace/apps/support/1084861/spike/?queryID=97f8205f39b71c03f3bb6c8512a8e67a) 2. Generate and copy a new API token from the [Spike dashboard](https://app.spike.sh/api) 3. Follow the instructions on Zendesk to connect Spike ### How to use #### Create tickets manually From the incidents table, select one or more incidents and create a Zendesk ticket. {% hint style="info" %} Tickets created this way are not synced with statuses or notes. For full sync, use the Spike app in Zendesk (Zendesk Marketplace app). {% endhint %} #### Automate ticket creation with Playbooks Use [Playbooks](/playbooks/introduction-to-playbooks) to automate ticket creation when an incident triggers. Incident details and timestamps are sent to Zendesk automatically. ### FAQs #### Who can set up the integration and create tickets? Anyone in your organization can set up the integration and create or sync tickets with incidents. No special permissions are required. #### Can I link multiple incidents to one Zendesk ticket? Yes. Multiple incidents can be linked to a single Zendesk ticket. # Freshdesk Connect Freshdesk to Spike to create tickets from incidents, and check or act on incidents from within Freshdesk.

## Freshdesk Spike's Freshdesk integration creates tickets from incidents. Freshdesk users can also check and act on incidents without leaving Freshdesk. {% embed url="" %} ### Set up Freshdesk can be connected to Spike in two ways. The first is an API connection. Use this to create tickets in Freshdesk from Spike incidents. This is one-way and does not sync statuses or notes. The second is the Spike app from the Freshdesk Marketplace. This allows Freshdesk users to check incidents and take action from Freshdesk. #### API connection 1. Go to [Settings > General > Helpdesk Integrations](https://app.spike.sh/settings/general/organisation#org--helpdesk-ticket-management) 2. Enter your Freshdesk API token and subdomain #### Freshdesk Marketplace app 1. Install the Spike app from [Freshdesk Marketplace](https://www.freshworks.com/apps/spike) 2. Generate and copy a new API token from the [Spike dashboard](https://app.spike.sh/api) 3. Follow the instructions on Freshdesk to connect Spike ### How to use #### Create tickets manually From the incidents table, select one or more incidents and create a Freshdesk ticket. {% hint style="info" %} Tickets created this way are not synced with statuses or notes. To act on incidents from Freshdesk, use the Spike app (Freshdesk Marketplace app). {% endhint %} #### Automate ticket creation with Playbooks Use [Playbooks](/playbooks/introduction-to-playbooks) to automate ticket creation when an incident triggers. Incident details and timestamps are sent to Freshdesk automatically. ### FAQs #### Who can set up the integration and create tickets? Anyone in your organization can set up the integration and create tickets. No special permissions are required. #### Can I link multiple incidents to one Freshdesk ticket? Yes. Multiple incidents can be linked to a single Freshdesk ticket. # Supportpal Connect Supportpal to Spike to create support tickets directly from incidents, syncing incident data one-way to Supportpal.

## Supportpal Spike's Supportpal integration creates support tickets from incidents. It's a one-way sync, and incident data flows from Spike to Supportpal. ### Set up 1. Go to [Settings > General > Helpdesk Integrations](https://app.spike.sh/settings/general/organisation#org--helpdesk-ticket-management) 2. Enter your Supportpal API token and subdomain ### How to use #### Create tickets manually From the incidents table, select one or more incidents and create a Supportpal ticket. #### Automate ticket creation with Playbooks Use [Playbooks](/playbooks/introduction-to-playbooks) to automate ticket creation when an incident triggers. Incident details and timestamps are sent to Supportpal automatically. ### FAQs #### Who can set up the integration and create tickets? Anyone in your organization can set up the integration and create tickets. No special permissions are required. #### Can I link multiple incidents to one Supportpal ticket? Yes. Multiple incidents can be linked to a single Supportpal ticket. # War rooms War rooms create instant meeting links tied to incidents, so your team can join a call without scrambling for a link.

## War rooms When an incident triggers and your team needs to coordinate on a call, war rooms create an instant meeting link tied to the incident. Everyone knows exactly where to join. Spike supports: 1. Google Meet 2. Zoom *(coming soon)* 3. Your personal room link (Daily.co, Gather.town, or any URL) ### Set up Go to **Organization Settings > Video Conferencing** and connect Google Meet or add a personal room link. For a personal room, paste the link and it's ready to use.

Video Conferencing settings in Spike Organization Settings — Video Conferencing in Organization Settings.

#### How Google Meet links work Spike connects to your Google account and requests permission to access Google Calendar. When a war room is created, Spike creates a calendar event on your account and generates a Meet link from it. {% hint style="success" %} Spike does not read your calendar events or store them. It only creates a calendar event to generate the Meet link. {% endhint %} ### Create a war room Open the incident page and click **Start Google Meet** from the Quick Actions menu.

Start Google Meet from the incident page Quick Actions menu — Start a war room from the incident page.

### Invite others to join When creating the war room, you can invite current responders, escalation members, or the entire team. You can also search for specific teammates to add.

Invite members while creating a war room in Spike — Invite members while creating the war room.

{% hint style="warning" %} Spike's Google App is currently pending verification for extended access to calendar scopes. {% endhint %} # Introduction to On-call schedules On-call schedules define who is on-call and when. Members rotate automatically on daily, weekly, or custom intervals. On-call schedules define who responds to incidents and when. Spike rotates your team automatically on daily, weekly, or custom intervals you set.

Example of daily rotation among 2 members on Spike — Example of daily rotation among 2 members.

## FAQs ### Who should use on-call schedules? Any team with more than one member. Schedules distribute on-call responsibility so no single person is always on call. ### Who can create schedules? Admins and members can both create and edit schedules. Use fine-grained access control to manage on-call permissions. ### Does being on-call mean I receive all alerts? No. You receive alerts only from escalation policies that include you. Being on-call doesn't automatically route all incidents to you. # Create On-call schedule Step-by-step guide to setting up an on-call schedule in Spike to define who's on-call, and when, across your team. ## Key components Every on-call schedule is built from layers (covered on the next page). Each layer has four components: 1. **Team members**: the people who will be on-call 2. **Rotation**: how long each on-call shift lasts 3. **Handoff**: the time of day when the shift rotates to the next person 4. **Slots**: optional time windows within a shift (covered separately) ## Create a schedule {% hint style="info" %} Not sure where to start? Spike offers [on-call templates](https://spike.sh/templates/oncall-templates) with pre-built schedule configurations. {% endhint %} Go to the [On-call section](https://app.spike.sh/on-calls) and click **New schedule**.

New schedule button in the on-call section.

### Step 1. Add members Add at least one member. The order determines the rotation sequence. The first member goes on-call first. {% hint style="info" %} Use the live preview calendar while creating the schedule to see how the rotation looks. {% endhint %}

You can rearrange the member order at any time, including while editing an existing schedule. {% embed url="" %} ### Step 2. Select rotation Choose a rotation type that works for your team.

Selecting rotation type for an on-call schedule.

### Step 3. Set handoff time Handoff time is when the current person's shift ends and the next person's begins.

Setting handoff time for an on-call schedule.

Here's what a completed daily rotation schedule looks like: 2 members, rotating daily, with handoff at 11:00 AM. Each member is on-call for 24 hours at a time.

The calendar shows who's on-call at any given time. Use it to plan coverage across upcoming dates.

On-call calendar showing coverage after creating a schedule.

## Add to an escalation policy A schedule only works if it's added to an [escalation policy](/escalations/introduction-to-escalations). Without this, alerts won't route to the person who's on-call. Add the schedule to your escalation policy the same way you'd add any team member. You can add it at any step in the policy.

On-call schedule added to an escalation policy.

{% hint style="success" %} Add the schedule at the first step of your escalation policy to route alerts directly to whoever is on-call. {% endhint %} # Slots in schedules Slots restrict on-call coverage to specific hours or days within a shift, so members aren't on-call around the clock. Slots define specific windows within an on-call shift. Members are only alerted during the hours you configure. You can apply different slots to different layers. There are two types: * **Time of day**: limit on-call to certain hours each day * **Days of week**: limit on-call to specific days and hours ## Slots for specific times of day Members are on-call only during the hours you set. In the example below, the member is on-call from 6 PM to 9 AM every day for Layer 1.

On-call slot from 6 PM to 9 AM every day — On-call from 6 PM to 9 AM every day.

## Slots for specific times and days of week Members are on-call only on the days and hours you set. In the example below, members are on-call every Monday 6 PM to Tuesday 9 AM, and Thursday 6 PM to Friday 6 PM, for Layer 1.

On-call slot for specific days and times of the week — On-call Monday 6 PM to Tuesday 9 AM, and Thursday 6 PM to Friday 6 PM.

## How to add slots While creating or editing an on-call schedule, find the option to add slots in each layer. Slots added to a layer affect the entire on-call schedule.

Add slots to each layer in an on-call schedule — Add slots on each layer.

## Use cases **Time of day slots:** * Non-office hours coverage: e.g. 6 PM to 9 AM daily. * Split coverage across layers: 12 AM to 8 AM for Layer 1, 8 AM to 4 PM for Layer 2, 4 PM to 12 AM for Layer 3. This rotates 8-hour duties across members daily or weekly. **Days of week slots:** * Weekdays only: Monday 9 AM to Friday 6 PM. * Skip a maintenance day: use multiple slots to exclude a specific day. To exclude Thursday, set Monday 9 AM to Thursday 12 AM, then Friday 12 AM to Monday 9 AM. {% hint style="danger" %} Avoid overlapping time windows across slots. If one slot runs Monday 9 AM to Thursday 9 AM and another runs Tuesday 9 AM to Friday 9 AM, Tuesday and Wednesday are covered by both. This causes unexpected behavior. {% endhint %} # Layers in on-call schedules Layers let you stack multiple on-call configurations within a single schedule. When two layers overlap, the higher-numbered layer takes over. Each on-call schedule can have one or more layers. Every layer has its own members, rotation, handoff times, and slots. When two layers overlap, the higher-numbered layer takes over. ## Example: weekday and weekend coverage This example has two layers: * **Layer 1:** Daily rotation among 2 members, covering all days * **Layer 2:** One person on-call each weekend, rotating weekly from Friday 6 PM to Monday 9 AM Layer 1 is the base. One of the two members is on-call every day of the week.

Single layer on-call schedule with daily rotation — Layer 1: daily rotation among 2 members.

Calendar view of a single-layer on-call schedule — Calendar view with Layer 1 only.

Layer 2 covers weekends only. It runs from Friday 6 PM to Monday 9 AM with a weekly rotation.

Layer 2 on-call schedule for weekend coverage — Layer 2: weekend coverage from Friday 6 PM to Monday 9 AM.

Calendar view with two layers showing weekday and weekend coverage — Calendar with both layers: weekday and weekend coverage.

Layer 2 was added so the members rotating on Layer 1 get a break over the weekend. Layer 2 overrides Layer 1 from Friday 6 PM to Monday 9 AM. ## How layers work Layers are ordered sequentially. When two layers share overlapping time windows, the higher layer overrides the lower one. If Layer 1 and Layer 2 overlap, Layer 2 is active during that window. In a three-layer schedule, Layer 3 overrides both Layer 1 and Layer 2 wherever they overlap. {% hint style="info" %} Layer order matters. If your weekend layer is Layer 1 and your weekday layer is Layer 2, the weekend layer will never take effect because Layer 2 always takes precedence. There is no limit on the number of layers in a single schedule. {% endhint %} ## FAQs ### Can I add a layer temporarily? Yes. You can also use [on-call overrides](/oncall-schedules/override-an-on-call) for short-term coverage changes. ### How many layers can I add? There is no limit. That said, too many layers can make the schedule hard to follow. ### How many members can be added in one layer? There is no limit. # Override an on-call On-call overrides assign temporary, one-time shift coverage for a member without changing the underlying schedule.

Overrides are one-time, non-recurring adjustments. Use them when someone needs short-term coverage without altering the schedule itself. ## Adding an override From your [on-call schedule](https://app.spike.sh/on-calls), press `O` or click **Override**. Add the team member's name, start and end time, and an optional comment for context. Save to apply. There are two ways to use overrides: {% tabs %} {% tab title="Cover a user's shift" %} The override replaces a specific member's on-call time. In the example below, Chen Taylor covers Maya Khan's shift from June 18th, 2026 (9:00 AM) to June 19, 2026 (9:00 AM).

Override covering a specific user's shift

{% endtab %} {% tab title="Cover everyone's shift" %} The override takes over all on-call responsibilities for the selected time window. In the example below, James covers everyone's shifts from June 22nd, 2026 (9:00 AM) to June 29th, 2026 (9:00 AM).

{% endtab %} {% endtabs %} ## FAQs ### Can I add multiple overrides for the same time period? Yes. If overrides overlap, the most recently added override takes precedence. ### Can I override the schedule for multiple team members at once? No. Each override covers one user. Add separate overrides for each member you want to cover. ### Are notifications sent when an override is added or removed? Yes. Team members involved in the override receive notifications about the change. ### Who can add or remove overrides? Anyone without a Viewer role can add and delete overrides. This permission is fixed and cannot be customized. # Notifications for on-call shifts Spike notifies you when your on-call shift starts or ends, across both personal channels and shared team channels.

## Notifications for on-call shifts Spike notifies you when your on-call shift starts or ends. Personal notifications go directly to you. Team notifications go to shared channels like Slack, Teams, and Discord. ### Personal notifications

Personal on-call shift notification settings — Personal notification settings for shift start and end.

Spike sends personal notifications via phone call, SMS, WhatsApp, Telegram, and Email when your shift starts or ends. To enable: 1. Visit [On-call notifications in settings](https://app.spike.sh/settings/personal-on-call). 2. Enable notifications separately for **Shift Start** and **Shift End**. 3. Once saved, the settings apply to all on-call schedules you are part of. {% hint style="info" %} You can override these per schedule. Visit **On-call > Settings > My alerts**. {% endhint %} ### Team notifications

Slack notifications for on-call shift start and end — Slack notifications when any team member's shift starts or ends.

Spike notifies a shared channel when any team member starts or ends their shift. This works with Slack, Microsoft Teams, and Discord. To enable: 1. Visit [Slack settings under Organisation > Alerts](https://app.spike.sh/settings/general/alerts). 2. Select one or more channels to receive notifications. 3. Once saved, all members in the selected channels receive shift start and end updates. Similar settings are available for Microsoft Teams and Discord. {% hint style="info" %} Slack and Microsoft Teams notifications can be overridden per schedule under the schedule's settings. {% endhint %} ### Webhook trigger on shift rotations

Webhook triggers for on-call shift start and end — Webhook payloads for shift start and end events.

Configure outbound webhooks to trigger on shift rotations using POST, PUT, or GET requests. Spike sends a webhook each time a shift starts or ends, with a separate request for each event. If one shift ends and another begins immediately, Spike triggers both the end and start webhooks in quick succession. Each has its own payload. The webhook payload includes details about the on-call schedule and the shift member. {% tabs %} {% tab title="Shift starts payload" %} ``` { "event_type": "oncall_shift_start", <---- EVENT DIFFERS "organization": { "id": "65f15fd64171a1487c4fe666", "name": "spike" }, "user": { "id": "660bb3f8324701c2f2e24c98", "firstName": "John", "lastName": "Doe", "email": "johndoe@example.com" }, "oncall": { "id": "67a20db2c9f79829b51fbf80", "name": "Weekday after office hours rotation", "url": "https://app.spike.sh/on-calls/67a20db2c9f79829b51fbf80", <-- permalink "shift": { "id": "67f3c5e9f6dd8715782cc7b2", "start": "2025-05-26T10:23:20.294Z", <-- times in UTC "end": "2025-05-26T18:30:00.000Z" } } } ``` {% endtab %} {% tab title="Shift end payload" %} ``` { "event_type": "oncall_shift_end", <---- EVENT DIFFERS "organization": { "id": "65f15fd64171a1487c4fe666", "name": "spike" }, "user": { "id": "660bb3f8324701c2f2e24c98", "firstName": "John", "lastName": "Doe", "email": "johndoe@example.com" }, "oncall": { "id": "67a20db2c9f79829b51fbf80", "name": "Weekday after office hours rotation", "url": "https://app.spike.sh/on-calls/67a20db2c9f79829b51fbf80", <-- permalink "shift": { "id": "67f3c5e9f6dd8715782cc7b2", "start": "2025-05-26T10:23:20.294Z", <-- times in UTC "end": "2025-05-26T18:30:00.000Z" } } } ``` {% endtab %} {% endtabs %} ### FAQs #### Can I receive on-call shift notifications via multiple channels? Yes. You can enable phone calls, SMS, WhatsApp, Telegram, and Email for personal notifications. Team notifications can go to Slack, Microsoft Teams, and Discord simultaneously. #### Are on-call notifications available on all plans? Yes, on-call notifications are available on all plans. #### Can I disable notifications for a specific on-call schedule? Yes. Visit **On-call > Settings > My alerts** to override notification settings per schedule. #### Do on-call notifications count toward my monthly alert quota? Yes. For plans with a monthly alert limit, on-call shift notifications count toward that quota. # Change on-call rotation day Change the rotation day on a weekly on-call schedule without losing coverage or disrupting the rotation order. Say you have a weekly on-call schedule rotating every Wednesday and want to switch it to Monday. This page covers how to make that change and how to handle the two issues that come with it. ## How to change the rotation day Use the **Schedule to start** option. This reschedules the on-call to begin on a new date without changing the members or rotation type. Visit **On-call schedule > Settings > Schedule to start**, set the next Monday (or whichever day you want), and save. ## What changes when you do this The system treats the updated schedule as a fresh start. Two things happen as a result: 1. **Coverage gap.** No one is on-call from now until the new start date. 2. **Rotation order resets.** The cycle restarts from the first member. For example, if A, B, C, D are in order and C is currently on-call with D due next, after the change A goes on-call first from Monday. D's turn gets pushed back. ## Fixing the gap and order To address both issues before making the change: 1. Add C as an [override](/oncall-schedules/override-an-on-call) to cover the gap until the new start date. 2. Update the member order to D, A, B, C. Visit **On-call schedule > Edit**, scroll to the layer, and drag names using the `::` handle to reorder them. This keeps coverage continuous and picks up the rotation where it left off. ## FAQs ### Can this be undone? No. To test changes safely, create a separate on-call schedule first and archive it afterward. ### Can I schedule to start in the past? No. The schedule to start option only supports future dates. # Sync with your calendar Sync your on-call schedule to Google Calendar, Apple Calendar, Outlook, or any calendar app that supports subscriptions. Spike generates a subscription link for your on-call schedule. Add it to Google Calendar, Apple Calendar, Outlook, or any app that supports calendar subscriptions. The link updates automatically when your schedule changes.


Google Calendar	Google Calendar	Google Calendar tile.png
Apple Calendar	Apple Calendar	Apple Calendar tile.png
Microsoft Outlook	Microsoft Outlook	Outlook Calendar tile.png

## Calendar link options You can choose what to sync: * **All my shifts across all on-call schedules**: every upcoming shift you are responsible for, regardless of schedule. * **My shifts for one on-call schedule**: your upcoming shifts in a specific schedule, useful when you're part of multiple schedules. * **All team members' shifts in one on-call schedule**: see who is on-call and who will be on-call at any time from your calendar. ## How calendar sync works The subscription link is a Webcal (iCalendar) feed. When your calendar app fetches the feed, Spike provides on-call data for the next six months. If you make changes to the schedule in Spike, they'll appear in your calendar the next time your app refreshes the feed. The update interval depends on your calendar app and can vary by provider. To set up calendar sync: 1. Go to your on-call schedule settings or the [calendar view of on-calls](https://app.spike.sh/on-calls/calendar). 2. Click **Calendar sync**. 3. Copy the subscription link, or click it directly if your browser offers to open it in your calendar app.

Copying the on-call calendar subscription link from Spike — Copy the subscription link from your on-call schedule settings.

## Works with any calendar The subscription link follows the iCalendar (Webcal) standard. It works with any calendar app that supports subscriptions, including Notion, Proton Calendar, Zoho Calendar, or your preferred calendar tool. ## FAQs ### How often does my calendar update? Your calendar app decides how often it refreshes the subscription. Spike always serves the latest data when requested. ### Can I share my calendar link with others? Yes, but sharing it will expose your schedule to whoever has the link. ### Does the calendar show past shifts? No. The feed only includes upcoming shifts for the next six months. ### What happens if my schedule changes? Your subscribed calendar will update the next time your app refreshes the feed. ### Can I unsubscribe later? Yes. Remove the subscribed calendar anytime from your calendar app's settings. # Google Calendar Sync your Spike on-call schedule with Google Calendar to see upcoming shifts alongside your other calendar events.

Export on-call schedule to your calendar

## Add on-call schedule to Google Calendar Keep your on-call shifts visible alongside your regular meetings in Google Calendar. By subscribing to your Spike on-call calendar, any updates to your schedule will appear automatically without needing to reimport anything. ### Subscribe to your on-call calendar 1. Go to the settings page for your on-call schedule. 2. Click **Calendar sync** and copy the subscription link. 3. Go to [Google Calendar](https://calendar.google.com/). 4. In the left sidebar, find **Other calendars** and click the **+** icon. 5. Select **From URL**, paste your Spike calendar link, and click **Add calendar**. Your on-call shifts will now appear in Google Calendar. The calendar refreshes automatically based on Google's update interval. {% hint style="info" %} If you are logged into your Google account, you can also click the calendar link directly from Spike. It will open Google Calendar and subscribe automatically. {% endhint %}


Apple Calendar		Apple Calendar	Apple Calendar tile.png
Microsoft Outlook		Microsoft Outlook	Outlook Calendar tile.png

# Apple Calendar Sync your Spike on-call schedule with Apple Calendar to see upcoming shifts alongside your other calendar events.

## Add on-call schedule to Apple Calendar View your Spike on-call shifts directly from the Calendar app on your Mac, iPhone, or iPad. By subscribing to your on-call calendar, updates will appear automatically whenever your calendar refreshes. ### Subscribe to your on-call calendar (Mac) 1. Go to the settings page for your on-call schedule. 2. Click **Calendar sync** and copy the subscription link. 3. Open the Calendar app on your Mac. 4. In the menu bar, click **File → New Calendar Subscription**. 5. Paste the link and click **Subscribe**. 6. Name your calendar and click **OK**. Your on-call shifts will appear automatically in the Calendar app. ### Subscribe from iPhone or iPad 1. Copy your Spike calendar link. 2. Go to **Settings → Calendar → Accounts → Add Account → Other**. 3. Tap **Add Subscribed Calendar**. 4. Paste the link and tap **Next**. 5. Tap **Save**. Your on-call schedule will now appear in the Calendar app and stay updated automatically. {% hint style="info" %} If you use iCloud Calendar, subscribing from your Mac will sync the on-call calendar across all your Apple devices automatically. {% endhint %}


Google Calendar		Google Calendar	Google Calendar tile.png
Microsoft Outlook		Microsoft Outlook	Outlook Calendar tile.png

# Microsoft Outlook Sync your Spike on-call schedule with Microsoft Outlook to see upcoming shifts alongside your other calendar events.

## Add on-call schedule to Outlook Calendar View your Spike on-call shifts directly in Outlook on the browser or desktop. Any changes made in Spike will appear automatically in Outlook. ### Subscribe in Outlook on the browser 1. Go to the settings page for your on-call schedule. 2. Click **Calendar sync** and copy the subscription link. 3. Open [Outlook](https://outlook.com) and sign in. 4. In the left sidebar, select **Add calendar**. 5. Choose **Subscribe from URL**. 6. Paste your Spike calendar link. 7. Enter a name for the calendar and click **Import**. Your on-call schedule will now appear in your Outlook Calendar view. ### Subscribe in Outlook Desktop (Windows or macOS) 1. Copy your calendar subscription link from Spike. 2. In Outlook, go to **File → Account Settings → Account Settings**. 3. Under the **Internet Calendars** tab, click **New**. 4. Paste the Spike calendar link and click **Add**. 5. Enter a name for the calendar and click **OK**. The calendar will appear under **Other Calendars** in Outlook and update automatically. {% hint style="info" %} Outlook checks for calendar updates automatically. You'll always see the latest schedule whenever Outlook refreshes your subscription. {% endhint %}


Google Calendar		Google Calendar	Google Calendar tile.png
Apple Calendar		Apple Calendar	Apple Calendar tile.png

# Linked calendars Add external or holiday calendars as overlays on your on-call schedule to plan shifts around holidays and team events.

## Linked calendars Linked calendars display external or holiday calendars as overlays on your on-call schedule. Use them to plan shifts around holidays, regional events, or company-wide leaves. They do not modify or affect any existing on-call shifts.

Holiday calendar overlaid on an on-call schedule — A holiday calendar overlaid on the on-call schedule.

### Adding a linked calendar Visit the [Linked Calendars](https://app.spike.sh/oncalls/linked-calendars) section on your dashboard. You can upload an `.ics` file or link directly from Google Calendar or Outlook.

Link a calendar on Spike — Link a calendar from the Linked Calendars section.

{% tabs %} {% tab title="Upload ICS file" %} 1. Export your calendar as a `.ics` file from Google, Outlook, or another calendar app. 2. In the Linked Calendars section, click **+ Link a calendar** and choose **Upload file**. 3. Select your `.ics` file and click **Link**. The imported calendar appears as an overlay. Toggle visibility anytime using the checkbox beside its name. {% endtab %} {% tab title="Link from Google Calendar" %} 1. In Google Calendar, go to **Settings → Integrate calendar**. 2. Copy the **Public address in iCal format**. The calendar must be set to public. 3. In the Linked Calendars section, click **Link calendar**, choose **From link**, and paste the link. {% endtab %} {% tab title="Link from Outlook Calendar" %} 1. In Outlook Calendar, go to **Settings → View all Outlook settings → Calendar → Shared calendars**. 2. Under **Publish a calendar**, select the calendar and permissions, then copy the ICS link. 3. In the Linked Calendars section, click **Link calendar**, choose **From link**, and paste the link. {% endtab %} {% endtabs %} {% hint style="info" %} Spike only reads data from linked calendars. It cannot write, modify, or delete any events on external calendars. {% endhint %} ### Managing linked calendars All linked calendars appear in the [Linked Calendars list](https://app.spike.sh/oncalls/linked-calendars) below your on-call calendar. * **Toggle on/off:** Use the checkbox beside a calendar name to show or hide it on the on-call view. * **Refresh data:** Click **Refresh** beside a calendar to fetch the latest events. Spike refreshes all calendars automatically every 24 hours at midnight UTC. Only users who can modify on-call schedules can add, delete, or manage linked calendars. {% hint style="info" %} Linked calendars are shared across the team. Toggling visibility, adding, and deleting linked calendars affects everyone's view. {% endhint %} ### FAQs #### Can I link multiple calendars? Yes. All linked calendars appear as overlays on your on-call calendar. #### Does linking a calendar change my on-call schedule? No. Linked calendars are for reference only and do not modify or offset any on-call shifts. #### How often do linked calendars refresh? Calendars added via public links refresh automatically every 24 hours at midnight UTC. You can also refresh manually anytime by clicking **Refresh** beside the calendar name. #### Who can add or manage linked calendars? Anyone with permission to modify on-call schedules can add, delete, or manage linked calendars. #### Can I hide a calendar without deleting it? Yes. Toggle visibility on or off using the checkbox beside each calendar. The change applies to everyone in the workspace. # Introduction to Live Call Routing Live Call Routing gives your team a dedicated phone number that routes incoming calls straight to the on-call engineer.

## Live Call Routing Live Call Routing gives your team a dedicated phone number that routes incoming calls to the on-call engineer. It captures human-reported incidents: a security vendor flagging a breach, or a payment partner reporting a failure. The caller connects directly to whoever is on-call. {% hint style="success" %} Live Call Routing is available on **all paid plans**. {% endhint %} ### How Live Call Routing works

Live Call Routing flow showing on-call and fallback responders — Incoming calls route through on-call and fallback responders.

Spike uses your on-call schedules to determine who receives calls. * An incoming call first rings the configured on-call responder. * If there is no answer, it rings fallback responder 1. * If still unanswered, it rings fallback responder 2. * If no one answers, Spike plays your configured **No Answer** message and takes a message from the caller. {% hint style="info" %} Voicemail pickup counts as an answered call. Spike will not route to a fallback responder in this case. {% endhint %} Every call is recorded and logged. A detailed alert is sent to your configured Slack or Microsoft Teams channels. ### How to set up Live Call Routing Visit [Live Call Routing](https://app.spike.sh/call-routing) on the dashboard to get started. Live Call Routing works with any phone number from Twilio or Plivo. Use an existing number you already own, or purchase a new one directly from Twilio or Plivo. Your number stays completely private. Spike does not require API keys or direct access to your account. {% hint style="info" %} To get a number directly from Spike, email . {% endhint %} {% content-ref url="/pages/Y8aE8oXq5bgLbGl5vIHU" %} [Configuring with Twilio](/live-call-routing/lcr-with-twilio) {% endcontent-ref %} {% content-ref url="/pages/md1UtAnk4WBgwdeOfWrD" %} [Configuring with Plivo](/live-call-routing/lcr-with-plivo) {% endcontent-ref %} {% stepper %} {% step %} #### Add your phone number Enter your phone number in full international format, including the `+` symbol. Give it a clear name (e.g., *Engineering Hotline*) for easy identification. {% hint style="info" %} Find your number in Twilio under **Console → Develop → Phone numbers → Active numbers**, or in Plivo under **Numbers → Active**. {% endhint %} {% endstep %} {% step %} #### Configure who receives the calls Select an on-call schedule or a specific responder. Optionally add up to two fallback responders. {% endstep %} {% step %} #### Customize your messages Set up three audio messages: * **Welcome message**: played when someone calls. * **No one on-call message**: played if no one is currently on call. * **No answer message**: played if all responders fail to answer. {% endstep %} {% step %} #### Connect your Twilio or Plivo account Spike provides a webhook URL. Paste it into your Twilio or Plivo console as per their instructions. {% endstep %} {% step %} #### Go live Your phone number is now ready to start routing calls. {% endstep %} {% endstepper %} ### Call recording setup When call recording is enabled, Spike retrieves recordings directly from your Twilio or Plivo account. To play recordings inside Spike, disable **HTTP Basic Authentication for media access** in your provider's settings. {% tabs %} {% tab title="Twilio" %} In your Twilio Console, go to **Develop → Voice → Settings → General**. Under **HTTP Basic Authentication for media access**, select **Disable**. {% endtab %} {% tab title="Plivo" %} In your Plivo Console, go to **Voice → Settings → Other Settings**. Under **HTTP Basic Authentication for media access**, select **Disable**. {% endtab %} {% endtabs %} ### Customize messages

Custom message configuration for Live Call Routing — Configure the three audio messages for your phone line.

Spike plays audio messages at key points during a call. Configure three types: #### Welcome message Played as soon as the call begins. Use it to greet callers and let them know they're being connected to the on-call team. *Example: "Hi, thanks for calling the Engineering Hotline. Please hold while we connect you to the on-call engineer."* #### No one answered message Played when no one answers after trying the primary and fallback responders. Ask the caller to leave a voicemail after the beep. *Example: "Sorry, no one is available to take your call right now. Please leave a message and we'll get back to you as soon as possible."* #### No one on-call message Played when there is no on-call responder at the moment. *Example: "Our on-call team is currently offline. Please leave a message with your name and number, and we'll return your call as soon as we're back on shift."* ### Call logs and recordings

Call log in Live Call Routing — All calls appear in the Call Logs section of your dashboard.

All calls appear in the **Call Logs** section of your dashboard. Each log entry includes: * Caller information * Who answered (or if unanswered) * Fallback activity (e.g., "Primary did not answer → routed to Secondary") * Duration of the call * A link to the audio recording * Detailed activity log * Link to incidents From the log, you can: * Review the call for post-incident analysis * Create or link incidents directly from the log * Archive or delete entries when no longer needed ### Test mode Before going live, test your setup: 1. Enable **Test Mode** for 5 minutes. 2. During this time, all calls route directly to you. 3. Ask a colleague to call your number and confirm that routing, fallback, and messages work as expected. ### FAQs #### How many fallback responders can I add? Up to 2 fallback responders. #### I don't have a Twilio or Plivo account. How can I get started? Email . The Spike team can help with setup. #### What happens if no one is on-call? The caller hears your configured **No one on-call message**. Spike takes a message and creates a call log. #### Can I review past calls? Yes. All calls are logged with full details and a recording in the **Call Logs** section. #### Can I have a transcript of my call? Not yet. Transcripts aren't available currently. # Triggering incidents Trigger incidents from Live Call Routing calls either manually from the call log, or automatically after each call.

Triggering incidents from Live Call Routing

## How to trigger incidents There are two ways to trigger incidents from Live Call Routing calls: manually from the call log, or automatically after each completed call. ### Manual incident creation Open any call in the [call log](https://app.spike.sh/lcr) and click **Create incident**. Fill in: * **Title** * **Integration** * **Escalation policy** * **Priority** (optional) * **Severity** (optional) ### Auto-trigger incidents You can configure Spike to automatically trigger an incident after each incoming call is completed. {% hint style="info" %} A call is considered **complete** if: * It is answered and finishes normally, **or** * It goes unanswered (regardless of whether the caller left a message) {% endhint %} To set up automatic incident creation: 1. From [Live Call Routing](https://app.spike.sh/lcr), visit **Settings → Incidents** 2. Enable **Auto-trigger incident for Live Call Routing** 3. Choose: * The **integration** to use for this incident * The **escalation policy** to use. You can default to the escalation policy set on the selected integration. If the policy is updated on the integration later, the change applies automatically. 4. (Optional) Set a default **priority** and **severity** to help with alert routing or analytics. ### Auto-generated incident titles Each automatically triggered incident will have a title in this format: `On-call hotline: Call from Mitchell Starc (+14156040016) (33s)` This includes: * The Live Call Routing setup name * Caller name (if known) * Phone number * Duration of the call ### Incident payload Spike includes detailed metadata with each auto-triggered incident, so you can automate follow-up actions or run outbound scripts. ```json { "message": "On-call hotline: Call from Mitchell Starc (+14156040000) (33s)", "details": { "callId": "call_1234567890abcdef", "twilioCallId": "CA0a1b2c3d4e5f678901234567890abcd", "liveCallRouting": { "name": "On-call hotline", "number": "+12245550123", "recordingEnabled": true }, "call": { "calledAt": "2025-07-29T06:24:32.262Z", "answeredAt": "2025-07-29T06:24:55.801Z", "duration": 33, "recording": "https://api.twilio.com/2010-04-01/Accounts/AC123/Recordings/RE456" }, "caller": { "name": "Mitchell Starc", "number": "+14156040016" }, "receiver": { "id": "user_abcdef123456", "name": "Priya S.", "oncallId": "oncall_789xyz", "oncallName": "Backend Team" }, "details": "" }, "priority": "p1", "severity": "high", "teams": ["devops", "backend"], "title": "On-call hotline: Call from Mitchell Starc (+14156040016) (33s)" } ``` Use this payload to: * View who answered or missed the call * Track escalation behavior * Access the call recording * Run follow-up automation using Spike or external tools ### FAQs #### Can I trigger incidents for missed calls only? Yes. #### Can I customize the incident title? Not yet. The incident title is auto-generated using the routing name, caller name/number, and call duration to ensure uniqueness. #### Will changing the escalation policy on the integration affect auto-triggering? Yes, but only if you've selected to sync escalation with the integration. Any updates to the integration's escalation will automatically apply here. #### Can I use this with webhooks or automation tools? Yes. The incident payload contains detailed metadata (call ID, responder info, timestamps, etc.), which you can use in Spike's outbound webhooks or alert rules. # Configuring with Twilio Connect your Twilio phone number to Spike to enable Live Call Routing for incoming, human-reported incident calls.

Configure Twilio for Live Call Routing on Spike

## Configure your Twilio number for Live Call Routing Spike provides a webhook URL during Live Call Routing setup. Follow these steps to connect it with your Twilio number. {% stepper %} {% step %} #### Sign in to Twilio In your Twilio Console, go to **Develop → Phone Numbers → Manage → Active Numbers**. If you don't have a phone number, buy one from the Twilio dashboard first. {% endstep %} {% step %} #### Select your phone number Choose the number you want to use with Live Call Routing. {% endstep %} {% step %} #### Configure incoming call settings Scroll down to the **Voice** section. * For **When a call comes in**, select **Webhook** from the dropdown. * Paste your **Spike webhook URL** in the field. * Set the HTTP method to **HTTP POST**. {% endstep %} {% step %} #### Configure the fallback handler (optional) In the same section, find **If primary handler fails**. * Select **Webhook** from the dropdown. * Paste the **same Spike webhook URL**. * Set the HTTP method to **HTTP POST**. {% hint style="info" %} Save your changes by scrolling to the bottom of the page and clicking Save. {% endhint %} {% endstep %} {% step %} #### Access call recordings When call recording is enabled, Spike retrieves recordings directly from your Twilio account. * In your Twilio Console, go to **Develop → Voice → Settings → General**. * Under **HTTP Basic Authentication for media access**, select **Disable**. {% endstep %} {% endstepper %}

Twilio webhook settings for Live Call Routing

Once saved, your Twilio number will forward all incoming calls to Spike. Spike handles routing, fallbacks, and call logging automatically. {% hint style="info" %} Need help connecting your Twilio account? Reach out to . {% endhint %} # Configuring with Plivo Connect your Plivo phone number to Spike to enable Live Call Routing for incoming, human-reported incident calls.

Configure Plivo for Live Call Routing on Spike

## Configure your Plivo number for Live Call Routing Spike provides a webhook URL during Live Call Routing setup. Plivo requires you to create an XML application first, then connect it to your phone number. {% stepper %} {% step %} #### Create an application In your Plivo Console, go to **Voice → XML under Applications → New Application**. Give the application a name you can recognise later. Under the **Voice** section, select POST request and paste Spike's webhook URL under: * Primary answer URL * Fallback answer URL * Hangup answer URL (optional) Click **Create Application**.

Plivo XML application settings for Live Call Routing

{% endstep %} {% step %} #### Configure your phone number Visit **Phone Numbers → Active** and select your number. In the Number configuration section: * Select **XML Application** under Application Type * Select your previously created application under **Plivo Application** Click **Update**.

Plivo phone number configuration for Live Call Routing

{% endstep %} {% step %} #### Access call recordings When call recording is enabled, Spike retrieves recordings directly from your Plivo account. * In your Plivo Console, go to **Voice → Settings → Other Settings**. * Under **HTTP Basic Authentication for media access**, select **Disable**. {% endstep %} {% endstepper %} Once saved, your Plivo number will forward all incoming calls to Spike. Spike handles routing, fallbacks, and call logging automatically. {% hint style="info" %} Need help connecting your Plivo account? Reach out to . {% endhint %} # Playbooks A Playbook is a sequence of response steps Spike runs on an incident, triggered manually or automatically based on conditions. A Playbook is a sequence of response steps Spike runs on an incident. Set one up once, then trigger it manually or configure it to run automatically. {% hint style="info" %} Actions run in the exact order you define. Spike does not reorder them. {% endhint %} ## What Playbooks can do * Add responders based on severity or incident type * Set incident priority and severity * Create war rooms for team collaboration * Generate tickets in Jira, Linear, or ClickUp * Create support tickets in Zendesk or Freshdesk * Trigger external workflows via outbound webhooks ## How Playbooks run ### Manual runs Run any Playbook from an incident with a single click. Use this when you need to kick off a response sequence on demand. ### Automatic runs Set conditions on a Playbook and Spike runs it automatically on every incident that matches. Conditions can target severity, integration, or other incident properties. ## Permissions All team members can create, edit, and delete Playbooks by default. Advanced permission settings are available for teams that need granular control over read, write, and execution rights. ## Example use cases * **Critical incident response:** Add a response team, assign severity, and create a ticket in one click. * **Low severity management:** Set the incident to low priority and resolve it automatically. * **External communication:** Create a status page incident and notify subscribers automatically. * **Custom integrations:** Trigger scripts or external processes via outbound webhooks. * **Ticket triage:** Assign incidents to the right responders and set priorities based on keywords. * **Security breach:** Acknowledge the incident, open a high-priority support ticket, and trigger isolation protocols via webhook. # Actions in Playbooks All actions available in Spike Playbooks — run in the order you define — with examples of how to use each one. Each Playbook can include one or more of the following actions. Actions run in the order you define. ## Actions * **Add responder** — Add one or more team members to the incident. * **Mark priority as** — Set the incident priority from P1 to P5. * **Mark severity as** — Set the incident severity from SEV1 to SEV3. * **Trigger outbound webhook** — Send the incident payload to an external endpoint to trigger scripts or workflows. * **Use Title remapper** — Rewrite the incident title using a predefined template. * **Execute playbook** — Trigger another Playbook as part of this one. * **Create a War room** — Start a video conference on Google Meet or Zoom for team collaboration. * **Create a task on** — Log the incident as a task in Jira, Linear, or ClickUp. * **Create a support ticket on** — Open a ticket in Zendesk, Freshdesk, or Supportpal. * **Resolve incident** — Mark the incident as resolved. * **Acknowledge incident** — Mark the incident as acknowledged. * **Add links** — Attach static links to the incident, such as runbooks, PRs, or deploy pipelines. * **Create incident on status page** — Publish the incident to your status page and notify subscribers. * **Resolve incidents on status page** — Mark the status page incident as resolved. * **Resolve by timer after** — Automatically resolve the incident after a set duration. ## Examples ### Critical incident response **Conditions:** Payload contains high severity indicators, or the incident has occurred more than `x` times in the last `y` minutes. 1. Add responder — bring in senior engineers 2. Mark priority as P1 3. Mark severity as SEV1 4. Create a War room — start a Google Meet for immediate discussion 5. Create a task on Jira — log the incident for tracking ### Low severity auto-resolution **Conditions:** Payload contains low severity indicators. 1. Mark severity as SEV3 2. Mark priority as P5 3. Resolve incident ### Status page update 1. Create incident on status page — notify subscribers 2. Resolve incidents on status page — update subscribers on resolution ### Payment system glitch 1. Resolve incident 2. Create a support ticket on Zendesk — document the issue for customer outreach ### Auto-resolve with external trigger 1. Trigger outbound webhook — run custom analysis or alert external systems 2. Resolve incident # Automating Playbooks Set up Playbooks to run automatically on every incident that matches the conditions you define — no manual trigger needed. Automated Playbooks run on every incident that matches the conditions you define. No manual trigger needed. ## Setting up automation ### Step 1: Choose your trigger event The trigger is an incoming incident. ### Step 2: Select integrations and services Choose whether the automation applies to all integrations and services or only specific ones. ### Step 3: Define conditions (optional) * **Incident title** — match by keyword or regex * **Incident details** — match by payload key/value pairs or regex * **Incident occurrences** — trigger based on how many times an incident has occurred within a timeframe * **Priority or severity** — match by P1–P5 or SEV1–SEV3 Combine multiple conditions using AND/OR logic. For example: run the Playbook if the incident is P1 priority OR contains "Down" in its title. ### Step 4: Select incident status condition **Run on any incident:** Runs for every incident matching your conditions, on any status change — triggered, acknowledged, or resolved. **Run when all incidents:** Runs when all incidents in a set reach a specific status. Useful for coordinated actions across multiple incidents. ## Example use cases ### When an incident is triggered 1. **Automatic service recovery:** Trigger an outbound webhook to restart servers, run diagnostics, or scale resources. 2. **Keyword detection:** Detect severity from keywords in the incident title, alert teams, and update your status page. 3. **Critical integration incident:** For SEV1 incidents on a specific integration, set priority to P1, launch a War room, and run external scripts via outbound webhook. 4. **Customer-facing outage:** Acknowledge the incident, create a Zendesk ticket, and prepare customer support for communication. 5. **Service self-recovery:** Auto-acknowledge or resolve incidents triggered by service restart attempts. 6. **Performance degradation:** Trigger diagnostics via outbound webhook when performance metrics fall below thresholds. ### When incidents are acknowledged or resolved 1. **Post-incident review:** Trigger an outbound webhook to schedule a review once all incidents are resolved. 2. **System health recheck:** After acknowledging connectivity issues, run an automated health check via outbound webhook. 3. **Customer communication:** Update the status page and send resolution summaries when incidents are resolved. 4. **Resource scaling:** Initiate resource optimization after high-usage incidents are resolved. 5. **Infrastructure restoration:** Automate service restoration and backup checks following database incidents. # Run Playbooks manually Trigger any Spike Playbook manually from the dashboard or an incident page, and watch each action's progress live. Click the **Playbooks** button on the dashboard or any incident detail page to trigger a Playbook. A progress modal shows the status of each action as it runs. ## Run on multiple incidents A Playbook can run on a single incident or multiple incidents at once. This is useful when you want the same response actions applied across different incidents at the same time. ## Permissions All team members can trigger Playbooks by default. Admins can adjust execution rights as needed. ## Customization Playbooks run exactly as configured. There is no option to adjust actions at the time of triggering. ## Notifications and logging Manual Playbook runs are logged in Spike. No notifications are sent to team members when a Playbook is triggered manually. # Create a status page Create a public status page in Spike to communicate the health of your website, API, or any customer-facing service. A status page is a public-facing page that shows the current status of your system components: website, API, mobile app, or any service your customers depend on. To create one, open the Status Pages dashboard and click **New status page** from the dropdown in the top navigation.

## Fill in the details

Fill in the name and description. The slug you set here becomes the URL where your status page is publicly accessible at `https://statuspage.spike.sh/your-slug`. Upload a logo so customers can identify the page as yours. Set the visibility to **Public** to make the page accessible to anyone with the link. ## Add components Components represent the parts of your system you want to display status for — website, API, mobile app, or individual microservices. Enter them as a comma-separated list. Once they exist, you can [group related components under a parent](/status-pages/group-components-into-nested-components) to keep the list short.

Once created, your status page appears in the dashboard with uptime history for each component.

New status page in the Spike dashboard — Your status page in the dashboard.

{% hint style="info" %} Next, [style your status page](/status-pages/style-your-status-page) with your brand colors, or [add a custom domain](/status-pages/add-custom-domain-to-status-page). {% endhint %} # Group components into nested components Group related components on your Spike status page under a parent component, so a single row tells you whether anything inside it is unhealthy. Grouping components gives you fewer rows to scan, and a group's status tells you at a glance whether anything inside it is unhealthy. Put "India" and "Japan" under "Asia", or "SMS", "Slack" and "Phone" under "Alerting". These are called **nested components**.

Nested components grouped under a parent on a Spike status page

Nesting is exactly one level deep. A component that is nested cannot contain anything itself, so the dashboard only ever offers top-level components as parents. ## Nest a component Open the component's edit dialog and pick a **Parent component** from the dropdown. The dropdown lists only top-level components. To keep a component at the top level, leave the dropdown on **No parent (top level)**. If the component you are editing already has components nested under it, the dropdown is replaced by a line telling you to move or remove those first. ## Reorder and move components on the list On the components list, nested components appear as indented rows under their parent. Expand and collapse a parent to show or hide them. Each row's menu offers: * **Make top-level**: moves a nested component out of its group. * **Move under…**: moves a component into a group. * **Move up** / **Move down**: changes the component's position. You can also drag rows to reorder them. Reordering happens within a group: top-level components reorder among themselves, and nested components reorder inside their parent. ## How a parent's status is derived A parent's status is derived, never set by hand. It shows the worst status among itself and everything nested under it, from least to most severe: 1. **Operational** 2. **Planned maintenance** 3. **Degraded performance** 4. **Partial outage** 5. **Critical outage** So a parent whose child is in a partial outage shows a partial outage, even if the parent itself is fine. The parent's 90-day uptime graph folds in its nested components' bars the same way — each day shows the worst state across the group. ## Select a group when you declare an incident When you [declare an incident](/status-pages/create-public-incident-on-status-page), the affected-components picker is a tree with a search box. The search filters both levels, and a matching nested component keeps its parent visible.

Affected components tree with nested components on Spike status page

Ticking a parent is a shortcut that selects everything nested under it, and unticking it clears them. When only some of a parent's children are selected, the parent shows a partial tick. You still set a status for each selected component. ## What visitors see On the public status page, nested components are grouped under their parent behind a **Show nested components** / **Hide nested components** toggle that shows how many there are. Visitors can toggle any group themselves.

Nested components on a public Spike status page

A group starts expanded when the parent's status is anything other than operational, so nothing is hidden on a bad day, and starts collapsed when everything in it is healthy. Subscriber notification emails group the affected components under their parent and note how many nested components were affected. ## Archive a parent component A component that still has components nested under it cannot be archived. Spike refuses and tells you to move or archive the nested components first. ## FAQs ### Can I nest a component more than one level deep? No. Nesting is exactly one level. A component that is already nested cannot become a parent, which is why the **Parent component** dropdown only ever lists top-level components. ### Can I set a parent's status directly? No. A parent's status is always derived from the worst status among itself and its nested components. To change what a parent shows, change the status of whatever inside it is unhealthy. ### Does a parent's uptime graph include its nested components? Yes. Each day in the parent's 90-day graph shows the worst state across the group. If you move an existing component under a parent, the parent's graph recalculates across all 90 days, so the component's past outages show up in the group straight away. ### Does re-parenting a component affect an open incident? No. The incident keeps the same affected components. Moving one into or out of a group changes how it is displayed, not what the incident refers to. ### Why does a parent show a partly filled tick when I declare an incident? Some of its nested components are selected and some are not. Tick the parent itself to select all of them, and untick it to clear them. ### Do visitors' expand and collapse choices carry over between visits? No. Those choices are not saved. Each visit starts from the default: expanded when the parent's status is anything other than operational, collapsed when everything in the group is healthy. {% hint style="info" %} Next, [style your status page](/status-pages/style-your-status-page) to choose which components show historical uptime, or [declare an incident](/status-pages/create-public-incident-on-status-page) against a group. {% endhint %} # Style your status page Customize your Spike status page with your brand colors, logo, header, footer, and uptime display preferences. Visit [Themes](https://statuspage.spike.sh/themes) from the sidebar to access all styling options. Changes preview in real time before you publish. ## Header Customize the header color, add a logo, and include links to other parts of your website for consistent navigation. ## Cover image and color Customize the cover section with a background image or color. You can also hide the cover entirely for a minimal layout. ## Footer Add custom links, social media icons, and copyright information to the footer. ## Components and historical uptime For each component, choose whether to display historical uptime data. Showing uptime history adds transparency for visitors. {% hint style="info" %} Any non-operational status counts as downtime. Planned maintenance is excluded. {% endhint %} # Incidents on your status page Create public incidents on your status page dashboard and post updates as the situation evolves for your customers. Use the status page dashboard to create public incidents and keep customers informed as the situation develops. ## Declare an incident On your status page, click **Incidents** in the left sidebar, then click **Declare incident**.

Declare incident form on Spike status page

Fill in the **title** and **description** to describe the issue. Set the **impact** based on your assessment. You can update this as the situation develops. Set the **date and time** the incident was identified. Spike uses this to calculate outage duration for affected components. Select the **affected components** impacted by the incident. The picker is a tree, so use the search box to narrow it down, and tick a parent to select everything [nested under it](/status-pages/group-components-into-nested-components). For each component, set its current state: * **Operational**: The component is functioning correctly. * **Degraded performance**: The component is working but below normal performance. * **Partial outage**: The component is not working for some users or in some situations. * **Critical outage**: The component is not functioning for most users. * **Planned maintenance**: The component has scheduled maintenance. Consider creating a [Planned Maintenance event](/status-pages/create-planned-maintenance-on-status-page) instead. To **notify subscribers** by email, toggle on the notification option. Spike sends an email to all status page subscribers. ## Add updates to an incident Once the incident is created, it appears on your status page. Click into the incident to open it.

Incident page on Spike status page dashboard

As you learn more, post updates to keep subscribers informed. Click **Send an update**.

Send an update form on Spike status page

For each update, select the current incident status: * **Identified**: You have identified the cause or the fix. * **Resolved**: The issue is fixed. Move affected components back to Operational. * **Postmortem**: The issue is resolved. Use this to share findings and steps to prevent recurrence. * **Update**: A general update when none of the above statuses apply.

Incident updates timeline on Spike status page

Updates appear on your public status page immediately after posting. # Create planned maintenance on your status page Create a planned maintenance event on your status page to notify subscribers ahead of expected service impact. Planned maintenance events appear on your public status page and notify subscribers before and after the maintenance window. ## Create a planned maintenance event

Planned maintenance section in Spike status page dashboard

Click **Maintenance** in the left sidebar, then click **New planned maintenance**.

Create planned maintenance form in Spike

Fill in the **title** and **description** to explain the maintenance. Select the **components** the maintenance will affect. For example, mobile app maintenance may not affect backend APIs. Set the **start** and **end** date and time for the maintenance window. To email subscribers, check **Notify subscribers**. Spike sends notifications at the start and end of the maintenance window. ## View planned maintenance

Upcoming planned maintenance in Spike status page dashboard

The event appears in the **Upcoming** section on the Planned maintenance page. Click it to see full details.

Planned maintenance visible on public status page

Subscribers see the planned maintenance on your public status page. To make changes after creating it, see [Edit planned maintenance](/status-pages/edit-planned-maintenance). # Edit planned maintenance Edit an upcoming planned maintenance event on your status page to update its details, timing, or affected components.

Planned maintenance details page in Spike

On the planned maintenance details page, click **Edit** in the options menu at the top right.

Update any field, including the start and end date and time, then save. # Add a custom domain to your status page Host your Spike status page on a custom subdomain, like status.example.com, instead of the default spike.sh URL. ## Step 1: Add your domain in Spike Click **Host** in the top-right corner of your status page.

Host option in Spike status page settings

Enter your custom domain, for example `status.acme.com`.

## Step 2: Update your DNS settings In your domain's DNS settings, add a CNAME record pointing to `alias.spike.sh`. Spike adds your domain to its SAN certificate so your status page loads correctly over HTTPS. DNS changes can take up to 10 minutes to propagate. {% hint style="info" %} If your status page does not appear on your custom domain after 30 minutes, contact . {% endhint %} # Manage your subscribers Let visitors subscribe to your Spike status page so they get real-time updates on incidents and maintenance events. Visitors subscribe directly from your status page using email, RSS/Atom, Slack, or Microsoft Teams. From your settings, you can control who can subscribe, restrict by domain, and import subscribers in bulk. ## How to subscribe {% tabs %} {% tab title="Email" %}

Email subscription option on Spike status page

{% endtab %} {% tab title="RSS / Atom" %}

RSS/Atom subscription option on Spike status page

{% endtab %} {% tab title="Slack" %}

Slack subscription option on Spike status page

{% endtab %} {% tab title="Microsoft Teams" %}

Microsoft Teams subscription option on Spike status page

{% endtab %} {% endtabs %} ### Email subscription Email is the most common subscription method. Subscribers do not receive a confirmation email after subscribing. The subscribe button appears on both public and private status pages. Email notifications follow your status page theme. Set up branding [under Themes](https://statuspage.spike.sh/themes). {% hint style="info" %} Subscribers on private status pages must have a Spike account. {% endhint %} ### RSS subscription Subscribers can use an RSS or Atom feed to receive updates. Private status page feed URLs include a unique token. Use the RSS feed to post status updates to Slack or Microsoft Teams channels, or to automate updates across other systems. ## Configure subscriber control Open **Security & Access** in your status page settings ([link](https://statuspage.spike.sh/configure/security-access)) to control who can subscribe: * **Allow new subscribers**: enabled by default * **Restrict by email domain**: only specified domains can subscribe (add subdomains separately) * **Disable unsubscribe**: subscribers cannot remove themselves | Allow new subscribers | Subscribers with domains | Who can subscribe? | | --------------------- | ------------------------ | ---------------------------- | | Enabled | Disabled | Anyone | | Enabled | Enabled | Specified email domains only | | Disabled | Automatically disabled | No one | ## Import subscribers Open the **Subscribers** section from the sidebar ([link](https://statuspage.spike.sh/subscribers)) to see all active subscribers, delete individual subscribers, or import new ones via CSV. The CSV must include an **Email** header. No other fields are processed. {% hint style="info" %} Subscribers are scoped to each status page and cannot be shared across pages. To add the same subscribers to multiple pages, upload the CSV to each one. {% endhint %} ## Notify subscribers When creating incidents or posting updates, enable the notify option to send email and RSS updates to subscribers. This option is enabled by default. # Embed status page notifications on your website Embed live status notifications directly on your website so visitors see updates without visiting your status page. The embed feature displays live status notifications directly on your website. Visitors see updates without having to visit your status page separately.

Example status page notification embedded on a website

## When notifications appear After page load completes, the notification appears within 5 seconds. By default, it shows in the bottom-right corner. You can configure the position in your widget settings. {% hint style="info" %} Notifications support planned maintenance events and are shown once per visitor. {% endhint %} ## Set up Visit the **Widgets** section from the sidebar. Copy the code snippet and paste it before the closing `` tag on every page where you want the notification to appear. When creating or editing a planned maintenance event, enable **Show a banner to status page visitors**.

Enable Notify visitors option for planned maintenance in Spike

## Security Add your domains to the allowlist so the widget loads correctly. Use `*.example.com` to allow all subdomains. For local testing, add your testing domain (such as an [ngrok](https://ngrok.com) URL) to the allowlist temporarily. # Live status widget Embed a live status widget on your website so every visitor can check your system's real-time health at a glance.

Live status widget embedded on a website

The live status widget displays your system's current health directly on your website. Paste the code snippet into any page: footer, contact page, support docs, header dropdown, or sidebar. ## Status priority order The widget shows the highest-priority status across all your components: 1. Planned Maintenance 2. Critical Outage 3. Partial Outage 4. Degraded Performance 5. Operational For example, if components A, B, and C are in *Degraded Performance* and component D is in *Critical Outage*, the widget shows *Critical Outage*. ## Customisation Spike supports Light, Dark, and System themes out of the box. You can override Spike's default CSS to modify the look and feel. All HTML classes use the **`spike--`** prefix. ### How to enable 1. Visit your status page dashboard at 2. Navigate to **Widget** from the sidebar 3. Enable **Embed Live Status Page Widget**

4. Click **Get code** and paste it in your `` tag You can initialise the widget with configuration options: ```javascript ``` {% hint style="info" %} Adjust the loading and initialisation to fit your frontend stack. {% endhint %} {% tabs %} {% tab title="Large rounded corners" %}

Live status widget with large rounded corners

{% endtab %} {% tab title="Small rounded corners" %}

Live status widget with small rounded corners

{% endtab %} {% endtabs %} ## Security Add your domains to the allowlist so the widget loads correctly. Use `*.example.com` to allow all subdomains. For local testing, add your testing domain (such as an [ngrok](https://ngrok.com) URL) to the allowlist temporarily. # Create integration and service on our dashboard Integrations has to be added to a service. In this doc we will take you through the process of how to create a service and add any number of integrations to it. ## **What is a service?** **You can think of services as a microservice.** Services are a way to scope your internal services from your architecture. Each of your services can have multiple integrations and you can create an unlimited number of services. We highly encourage you to create different services for each of your different modules. [Learn more about services](https://docs.spike.sh/services/introduction-to-services-on-spike). ## Adding service ![](https://1743514643-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Ln3jS1bJTTsE3yoEcOu%2Fuploads%2Fgit-blob-19465a0fd708276bc23c67e4ec8e12b1c0e6263e%2Fimage.png?alt=media\&token=46a99c6b-38e9-4c29-812f-2d6ae9fd0877) You can create a new service by clicking on the [New Service button](https://app.spike.sh/services/new) on the [services page](https://app.spike.sh/services). Give it an appropriate name, **for ex: Billing service**. ( This way you can also integrate your payment gateway by adding another integration for every time payments fail ). Hit **Create service!** *** Once the service is created you will be able to see an overview of your service with all of it's integrations. ### Adding integration From the header, select Add integration. Optionally, on the sidebar select integrations and then add integration. ![Step 1 - Select an integration](https://1743514643-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Ln3jS1bJTTsE3yoEcOu%2Fuploads%2Fgit-blob-d5022c4749a8278cea3d90932609b5e9d73d66a1%2Fimage.png?alt=media\&token=3522ba4b-02bc-4338-b584-8808b4e52454) ![Step 2 - add service, escalation, Acknowledge timeout](https://1743514643-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Ln3jS1bJTTsE3yoEcOu%2Fuploads%2Fgit-blob-9324481cbba5049c1789d73f2c0d557e2b98e6ec%2Fimage.png?alt=media\&token=9d44f05a-14b5-48dd-948e-3d5596cc10d9) [Acknowledge timeout](https://docs.spike.sh/incidents/acknowledge-timeout) and repeat escalations are optional but we highly recommend it. ![](https://1743514643-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Ln3jS1bJTTsE3yoEcOu%2Fuploads%2Fgit-blob-3b41d63fc41f4925e3f5ba5606a3afa8e661717c%2Fcopy-webhook.png?alt=media\&token=5af4449a-dd9c-47da-b2af-cb6dde5b9dc3) The last bit on our dashboard is the final step of copying the webhook to be used on Pingdom used as an example here. So, get the webhook by clicking on the **Copy Webhook** button. ![Final step - copy the integration webhook](https://1743514643-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Ln3jS1bJTTsE3yoEcOu%2Fuploads%2Fgit-blob-1091b64a5a54a22a316533f09ec8cb105aaceb6a%2Fintegration-last.png?alt=media\&token=60e1ff3d-cd7e-42d5-9499-b37b05822ba5) {% hint style="danger" %} Make sure to use the Pingdom webhook in Pingdom. Using it on other integrations might not give you the proper incident messages and will not reliably group repeated {% endhint %} {% hint style="success" %} Not able to find an integration you are looking for?? Use the **Webhook** integration instead and paste it on any service. {% endhint %} # Setup integrations Step-by-step instructions for setting up any integration with Spike, from simple webhooks to native tool connections. Follow the simple instructions on how to setup an integration with Spike. {% content-ref url="/pages/-Ln3o57T7rleB\_NDguHi" %} [Integrate Spike with AWS](/integrations-guideline/integrate-spike-with-aws) {% endcontent-ref %} {% content-ref url="/pages/-Ln3oiGSeacmwuwdBHIK" %} [Integrate Spike with Google Cloud](/integrations-guideline/integrate-google-cloud-with-spike) {% endcontent-ref %} {% content-ref url="/pages/-M-JdUhWPmT7lJP1hjGG" %} [Integrating with Webhooks](/integrations-guideline/integrating-with-webhooks) {% endcontent-ref %} {% content-ref url="/pages/-Ln3orLYyop8UFMfFt7w" %} [Integrate Spike with Healthchecks](/integrations-guideline/integrate-healthchecks-with-spike) {% endcontent-ref %} {% content-ref url="/pages/-Ln3ouc0uT3e\_dlxfi5W" %} [Integrate Spike with Apex ping](/integrations-guideline/integrate-apex-ping-with-spike) {% endcontent-ref %} {% content-ref url="/pages/-Ln4PJS0-KCekPyWnz64" %} [Integrate Spike with Uptime Robot](/integrations-guideline/integrate-spike-with-uptime-robot) {% endcontent-ref %} {% content-ref url="/pages/-LupVuqDSI2W7hBR6x7e" %} [Integrate Spike with Sentry](/integrations-guideline/integrate-spike-with-sentry) {% endcontent-ref %} {% content-ref url="/pages/-LovtjoNaf81yqiKAdVW" %} [Integrate Spike with Pingdom](/integrations-guideline/integrate-spike-with-pingdom) {% endcontent-ref %} {% content-ref url="/pages/-MABBINnLk479vFR1BOg" %} [Integrate Spike with Twilio](/integrations-guideline/integrate-spike-with-twilio) {% endcontent-ref %} {% content-ref url="/pages/-MA\_mIqCDGSwMhX1FEBp" %} [Integrate Spike with Microsoft Azure](/integrations-guideline/integrate-spike-with-microsoft-azure) {% endcontent-ref %} {% content-ref url="/pages/-MAa4zECjZkmxpJgT1dO" %} [Integrate Spike with Honeybadger](/integrations-guideline/integrate-spike-with-honeybadger) {% endcontent-ref %} {% content-ref url="/pages/-MB3nw1P4yRo3RZqktPL" %} [Integrate Spike with Datadog](/integrations-guideline/integrate-spike-with-datadog) {% endcontent-ref %} {% content-ref url="/pages/-MAqc4pdqP4Uqf0CuBe4" %} [Integrate Spike with Travis CI](/integrations-guideline/integrate-spike-with-travis-ci) {% endcontent-ref %} {% content-ref url="/pages/-MB-1n5WpJBjpgVsoHOm" %} [Integrate Spike with Rollbar](/integrations-guideline/integrate-spike-with-rollbar) {% endcontent-ref %} {% content-ref url="/pages/-MB-MwcKIyKoYZe\_Poow" %} [Integrate Spike with Needle.sh](/integrations-guideline/integrate-spike-with-needle.sh) {% endcontent-ref %} {% content-ref url="/pages/-MB9PsFs-KllRTxT8yWU" %} [Integrate Spike with Cronitor](/integrations-guideline/integrate-spike-with-cronitor) {% endcontent-ref %} {% content-ref url="/pages/-MCltmiobhHTyx3eqLoR" %} [Integrate Spike with Bugsnag](/integrations-guideline/integrate-spike-with-bugsnag) {% endcontent-ref %} {% content-ref url="/pages/-MD0e0g4UX7g1jMF3wBr" %} [Integrate Spike with Prometheus](/integrations-guideline/integrate-spike-with-prometheus) {% endcontent-ref %} {% content-ref url="/pages/-MD0bKHfMKOaJuwv5bj0" %} [Integrate Spike with Grafana](/integrations-guideline/integrate-spike-with-grafana) {% endcontent-ref %} {% content-ref url="/pages/-MEMMUxQuVfmWEVdXC0h" %} [Integrate Spike with Instana](/integrations-guideline/integrate-spike-with-instana) {% endcontent-ref %} {% content-ref url="/pages/-MEOQC3s4HbvjL2nK3YS" %} [Integrate Spike with Zapier](/integrations-guideline/integration-spike-with-zapier) {% endcontent-ref %} # Archive an integration Step-by-step guide to archiving an integration in Spike from the integrations settings page in your dashboard. ## How to archive an integration? You can choose to archive any integration. Visit the integrations page, select an integration and click archive. ![archive any integration](https://1743514643-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Ln3jS1bJTTsE3yoEcOu%2Fuploads%2Fgit-blob-0ef91e98c9984134ca125473d0509845e796c716%2Farchive-integrations-1.png?alt=media\&token=90b7850d-4f93-42ca-b0a0-35f7c1b1cc10) {% hint style="info" %} Once the integration is archived, no new incidents will be created {% endhint %} ### Is it possible to retain a webhook after archiving? No. Once you archive any integration (ex: AWS) and then create a new one (ex: AWS) then the webhook will be different than the archived one. ### Does this affect existing incidents? No. In fact, the existing incidents will prompt you about archived integration to avoid misinformation. ![archived integration in existing integration](https://1743514643-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Ln3jS1bJTTsE3yoEcOu%2Fuploads%2Fgit-blob-4af5a3c7bbe79a1eb0da1c8da304f63c632c4c90%2Farchive-integrations-2.png?alt=media\&token=9726969a-7e7b-465a-9be6-2c5dfc911a3b) ### How to restore an integration? There is no automated process. If you certain about restoring then talk to us via chat from the dashboard or email us at # Integrating with Webhooks Use Spike's webhook integration to create an incident directly from your own code with a simple POST request today. ## Create an incident using our webhooks integration Each webhook is unique to the service and escalation policy. Make sure you create a webhook integration and copy the webhook URL. [Know how](https://docs.spike.sh/integrations-guideline/create-integration-and-service-on-dashboard). From your code, you can create an incident simply by making a **POST** request. ## Create an incident `POST` `https://hooks.spike.sh/:token/push-events` #### Path Parameters | Name | Type | Description | | ----- | ------ | ----------------------------------------- | | token | string | Unique token for your webhook integration | #### Request Body | Name | Type | Description | | -------- | ------ | ------------------------------------------------------------------------------------------------------------------------- | | title | string | This will be the title of your incident. Failing to add this will create an empty incident. Read more about this below 👇 | | body | string | Accepts objects and strings. This data will be in your incident details | | severity | string |

Sets the severity on your incident. Options are

sev1, sev2, and sev3.

| | priority | string |

Sets the priority on your incident. Options are

p1, p2, p3, p4, and p5

| {% tabs %} {% tab title="200 Cake successfully retrieved." %} ``` { Ok: true } ``` {% endtab %} {% tab title="500 Could not process your request." %} ``` {} ``` {% endtab %} {% endtabs %} The above request will create a new incident. Please make sure you have used the correct webhook URL. If you have copied the URL from the dashboard then the **token \_\*\*\*\***\_\*\* should already be present.\*\* A new incident is created soon as make a POST request. A successful request will get you 200 HTTP response status code. ### **When is a new incident NOT created?** If the integration has an open incident (*not resolved state*) \_\_ with the same title then a new incident will NOT be created. ### What is the title's significance? The **title** plays an important role really. A new incident will use this title and it will be sent on all alter channels. The title acts as a unique identifier to perform group actions, suppress repeated incidents and also to auto-resolve them. ### What happens if I miss adding a title? Failing to add **title** would create incidents with no message. This also means that it will NOT group, suppress or auto-resolve these incidents. {% hint style="info" %} We highly recommend you add a title to your POST request while creating an incident {% endhint %} ## Auto-resolve incident `POST` `https://hooks.spike.sh/:token/push-events` #### Path Parameters | Name | Type | Description | | ----- | ------ | ----------------------------------------- | | token | string | Unique token for your webhook integration | #### Request Body | Name | Type | Description | | ------ | ------ | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | status | string | **resolve** | | body | string | As of now, you can add any message about the incident you would like here. Accepts objects too. | | title | string | This will be the title of your incident. Failing to add this will create an empty incident title with all other parameters. Read more about this below 👇 | {% tabs %} {% tab title="200 Cake successfully retrieved." %} ``` { Ok: true } ``` {% endtab %} {% tab title="500 Could not process your request." %} ``` {} ``` {% endtab %} {% endtabs %} The above request will automatically resolve incidents. We use the title and the token to uniquely get open incidents and resolve them. All you need is to add the **status parameter as 'resolve'** in your POST request. The rest of the parameters are the same as creating incident request. {% hint style="warning" %} Make sure to have the same **title while resolving,** otherwise it won't work. {% endhint %} # Integrate Spike with Airbrake.io Integrate Spike with Airbrake.io to receive real-time alerts on Phone calls, SMS, Slack, MS Teams, and more for application error monitoring, ensuring faster incident response.

### Overview [Airbrake.io](https://airbrake.io) offers detailed error monitoring and performance management for your applications, helping teams detect, diagnose, and resolve issues in real-time. With detailed error reports, Airbrake.io helps maintain application's optimal performance and reliability. ### Incident alerts from Airbrake.io With the Spike integration, you can receive real-time alerts for various incidents detected by Airbrake.io. They include * Application errors * Performance issues * Exception handling problems * and much more This integration allows you to stay alert to all incidents triggered by [Airbrake.io](https://airbrake.io) for immediate incident response and resolution. {% hint style="info" %} Spike will automatically group repeated incidents and also suppress alerts while incident is open. You can set up [alert rules](https://docs.spike.sh/alerts/alert-rules) to determine incident severity and take actions accordingly. Auto-resolution is not supported. {% endhint %} *** ## Set up instructions **Step 1:** Create an Airbrake.io integration on [Spike dashboard](https://app.spike.sh/integrations) and Copy the webhook URL for your integrartion. {% content-ref url="/pages/-Ln3rb4wLUFeI-OAPcmq" %} [Create integration and service on our dashboard](/integrations-guideline/create-integration-and-service-on-dashboard) {% endcontent-ref %} **Step 2:** {% tabs %} {% tab title="Setup on Airbrake.io" %} * **Navigate to Integrations**: * Go to **Project's Settings > Select Integrations**. * **Add a Webhook**: * Scroll through the available integrations and **select Webhooks**. * Click on **Add Integration** * **Configure the Webhook**: * Set your reset condition (this will automatically resolve the incident on Spike). * **Configure Trigger Actions**: * Paste the Spike integration webhook URL into the field. * If applicable, adjust the triggering conditions and other settings based on your requirements. * If you see an option for setting headers, set the `ContentType` to `"application/json"` * Save the integration to enable real-time alerting. {% endtab %} {% endtabs %} # Integrate Spike with Akamai mPulse Integrate Spike with Akamai mPulse (formerly SOASTA) to receive real-time alerts via Phone calls, SMS, Slack, MS Teams, and more when your real user monitoring alerts fire. ## Overview [Akamai mPulse](https://www.akamai.com/products/mpulse-real-user-monitoring) (formerly SOASTA) is a real user monitoring (RUM) platform. It measures how real visitors experience your websites and apps, and lets you define alerts on timers and metrics such as page load time and bounce rate. With Spike's integration, you can receive an incident whenever an mPulse alert fires, including: * **Slow pages**: Page load time or other timers crossing the threshold you set. * **Engagement drops**: Metrics such as bounce rate moving outside the expected range. * **Traffic changes**: Unusual beacon counts in the evaluated window. {% hint style="info" %} Spike groups repeated alerts with the same **Alert Name** into one incident while it is open. You can configure [alert rules](https://docs.spike.sh/alerts/alert-rules) to define severity levels, change escalation policies, and trigger outbound scripts. {% endhint %} {% hint style="warning" %} mPulse does not document a notification when an alert clears, so Spike cannot resolve these incidents automatically. Resolve them from the Spike dashboard, Slack, or the mobile app. {% endhint %} *** ## Set up instructions **Step 1:** Create an Akamai mPulse integration in the Spike dashboard and copy the webhook URL. {% content-ref url="/pages/-Ln3rb4wLUFeI-OAPcmq" %} [Create integration and service on our dashboard](/integrations-guideline/create-integration-and-service-on-dashboard) {% endcontent-ref %} **Step 2:** {% tabs %} {% tab title="Setup on Akamai mPulse" %} 1. **Log in to mPulse** with a user who can edit alerts for your app. 2. **Open the alert:** Go to **Alerts** → **Alert Definitions** and click **+ New** (or open an existing alert definition). 3. **Add the webhook notification:** Under the notification step, click **+ Add an action** and choose **Call Webhook**. Set: * **Method**: `POST` * **URL**: the Spike webhook URL, `https://hooks.spike.sh//push-events` * **Header**: `Content-Type: application/json` * **Mode**: `Custom`

Set the Mode slider to Custom. In Auto, mPulse generates the URL query parameters and headers itself and you cannot write the body below.

4. **Set the body:** In the body, use this JSON. Replace each value by dragging the matching mPulse attribute in between the quotes: ```json { "alert_name": "Checkout page load time above 4s", "severity": "HIGH", "app_name": "shop-production", "beacon_count": "1842", "bounce_rate": "37", "network_error_rate": "2", "page_load_time": "4630 ms", "dns_resolution_time": "81 ms", "dom_load_time": "2210 ms", "dom_ready_time": "1980 ms", "back_end_time": "1356 ms", "ssl_time": "71 ms", "front_end_time": "3274 ms", "tcp_time": "20 ms" } ``` | Field | Required | What to put there | | ------------------------------------------------------------------------------------------------------------------------------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `alert_name` | Yes | The **Alert Name** attribute. It identifies the alert, so repeats join the same incident, and it is the start of the incident title. | | `app_name` | No | The mPulse app the alert watches. Added to the title as `on `. | | `severity` | No | The alert's severity (Info, Low, Medium or High; some mPulse pages call the top level Severe). High and Severe map to sev1, Medium to sev2, Low and Info to sev3. Not shown in the title. | | `beacon_count`, `bounce_rate`, `network_error_rate` | No | Readings at alert time, sent as strings. Context only. | | `page_load_time`, `dns_resolution_time`, `dom_load_time`, `dom_ready_time`, `back_end_time`, `ssl_time`, `front_end_time`, `tcp_time` | No | Timer readings at alert time, sent as strings with their unit. Context only. | Spike builds the incident title as ` on `, for example `Checkout page load time above 4s on shop-production`. The `on ` part is left out when the alert name already contains the app name as a whole word, and the title is cut to 200 characters. Readings and severity never appear in the title, so a repeat with new readings joins the open incident. If `alert_name` is missing, the title is `Akamai mPulse alert on `; with neither, it is `Akamai mPulse alert with no details`.

Do not add a top-level message key to the body, for example "message": "<Alert Name> fired". Spike then uses that text as the title for every alert instead of building it from alert_name and app_name.

If an attribute is left unexpanded (it arrives as text such as $alert_name, {{alert_name}} or %alert_name%), Spike treats it as missing. Two different alerts then cannot be told apart by name, so check that each value is replaced by the real mPulse attribute.

5. **Save the alert:** Save the alert. When it next triggers, check that the incident appears in Spike. {% endtab %} {% endtabs %} ## FAQs

Will incidents auto-resolve in Spike when the alert clears in mPulse?

No. mPulse does not document a notification when an alert clears, so resolve the incident in Spike.

Why should alert_name always be included?

Spike uses it to recognise repeats of the same alert. Without it, Spike can only match repeats by title, which then reads \`Akamai mPulse alert on \`, so different alerts on the same app would share one incident.

What if two alerts have the same name?

They share one Spike incident while it is open. mPulse requires alert names to be unique, so give each alert definition its own name.

What if no incidents show up in Spike?

Check that the webhook URL is correct, the method is \`POST\`, the content type is \`application/json\`, and the body is valid JSON.

# Integrate Spike with Apex ping Ping by Apex is a very beautiful minimalist uptime monitoring solution for businesses. Spike integrates with Apex ping using webhooks to alert you when your websites are down ## Service and Integration Make sure you have the service and integration already setup for Apex ping. Follow the link below on instructions of how to create integration and service {% content-ref url="/pages/-Ln3rb4wLUFeI-OAPcmq" %} [Create integration and service on our dashboard](/integrations-guideline/create-integration-and-service-on-dashboard) {% endcontent-ref %} ## Use the webhook on Apex ping Login into [Apex.sh/ping](https://ping.apex.sh/) account and visit the [alerts page](https://ping.apex.sh/alerts) to being your integration. ![](https://1743514643-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Ln3jS1bJTTsE3yoEcOu%2Fuploads%2Fgit-blob-731f60f84ad6c88046e821da727441b888a407d3%2Fapex-ping.png?alt=media\&token=1b6f42aa-1455-40f5-a19a-0c37b6f1eec3) Click on **add alerts** On the alerts page, you can add or edit an alert. 1. Select **Webhook** from the dropdown. 2. Paste the webhook 3. Customize your settings for alerts and **save.** {% hint style="success" %} This integration supports auto resolution. {% endhint %} ## FAQ 1. **How many services and integrations can I create on Spike?** * Unlimited 2. **How many escalation policies can I have on Spike?** * Unlimited At Spike, we are working hard to integrate with all the tools your business uses. We are on a mission to help **you** identify incidents/crashes/spikes before your customers do. If you have any integration in mind and would like us to build it for you then contact us at [support@spike.sh.](mailto:support@spike.sh) # Integrate Spike with APImetrics Send APImetrics API call alerts to Spike so a failing, slow or warning API call pages your on-call rotation by phone, SMS, Slack or Teams, and resolves when the call passes again. [APImetrics](https://apimetrics.io) monitors your APIs by calling them on a schedule from locations around the world. When a call fails, runs slow or breaks a warning threshold, APImetrics can send a webhook. Point that webhook at a Spike integration URL and the failing call pages your on-call rotation, repeat failures of the same call land on the incident already open, and the incident resolves itself when the call passes again. ## Prerequisites * An APImetrics account that can create alert actions * An APImetrics integration in Spike and its webhook URL ## Step 1 — Create the integration in Spike In Spike, go to **Integrations → Add integration → APImetrics**, attach it to a service and an escalation policy, and copy the webhook URL. It looks like `https://hooks.spike.sh//push-events`. {% content-ref url="/pages/-Ln3rb4wLUFeI-OAPcmq" %} [Create integration and service on our dashboard](/integrations-guideline/create-integration-and-service-on-dashboard) {% endcontent-ref %} ## Step 2 — Add a Generic webhook action in APImetrics 1. Sign in to APImetrics, open your project and choose **Alerts & Webhooks** in the left-hand navigation. 2. Click **+ Add new action**. 3. Set **Type** to **Generic** and give the action a name, for example `Spike`. 4. Toggle on the triggers **Fail**, **Warning**, **Slow** and **Pass**. Pass is what resolves the incident, so keep it on. 5. Optionally use **Include tags** and **Exclude tags** to limit which API calls page Spike, and set **Only alert after this many failures in a row** (0 alerts on every result). 6. Paste the Spike webhook URL from Step 1 into the **URL** field. Leave **HTTP Headers** empty and **Authentication** at **None**. 7. Make sure the **Enabled** toggle is on, and click **Save**. ## What APImetrics sends APImetrics posts this JSON body when an API call fails. Spike reads `call_id`, `result_class`, `result` and `context._notification`; the other fields are kept on the incident. ```json { "response_size": 0, "location_id": "public_googleuscentral1", "result_class": "FAIL", "call_id": "agpzfmFwaW1ldHJpY3NyFwsSClRlc3RTZXR1cDIYgICgyOqJ2QoM", "result_url": "http://client.apimetrics.io/tests/result/agpzfmFwaW1ldHJpY3NyGAsSC1Rlc3RSZXN1bHQzGICA0K_k-bsKDA/", "result": "DOWNLOAD_ERROR", "context": { "_result_category": "FAIL", "_result_streak": 3, "_notification": { "category": "FAIL", "owners": [ "agpzfmFwaW1ldHJpY3NyEQsSBFVzZXIYgICg5MuP0goM" ], "viewed_by": [], "title": "[FAIL]: APImetrics: All Failures: Checkout - Create order", "created": "2026-10-09T03:12:41.204518Z", "last_update": "2026-10-09T03:12:41.311902Z", "references": [ "agpzfmFwaW1ldHJpY3NyFwsSClRlc3RTZXR1cDIYgICgyOqJ2QoM", "agpzfmFwaW1ldHJpY3NyGAsSC1Rlc3RSZXN1bHQzGICA0K_k-bsKDA" ], "description": "\n

\nAPI Call \"Checkout - Create order\" has failed :\n

We could not connect to the API.
Calling POST https://api.acme-shop.com/v2/orders
Checking for connection issue...
... no problem found.
Couldn't resolve host. The given remote host was not resolved.
We could not connect to the API.
Couldn't resolve host 'api.acme-shop.com'

View details here: http://client.apimetrics.io/tests/result/agpzfmFwaW1ldHJpY3NyGAsSC1Rlc3RSZXN1bHQzGICA0K_k-bsKDA/

Sincerely,
APImetrics Team

\n" } }, "result_id": "agpzfmFwaW1ldHJpY3NyGAsSC1Rlc3RSZXN1bHQzGICA0K_k-bsKDA", "call_url": "http://client.apimetrics.io/tests/test/agpzfmFwaW1ldHJpY3NyFwsSClRlc3RTZXR1cDIYgICgyOqJ2QoM/", "response_time": 0 } ``` ### Required and optional fields | Field | Required | Used for | | ----------------------------------- | ----------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `call_id` | Yes | Identifies the monitored API call. It is the same on every run, so repeat failures join one incident and a pass resolves it | | `result_class` | Yes | `PASS` resolves the incident (`OK`, `RESOLVED`, `CLOSED` and `CLEARED` count as a pass too, in any case). Any other value, such as `FAIL`, `WARNING` or `SLOW`, opens or updates an incident. The class is added to the end of the title | | `context._notification.description` | Recommended | APImetrics' own sentence about what is wrong. It becomes the incident title | | `context._notification.title` | Recommended | The title when `call_id` is missing, and the call name when the description has no link | | `result` | Optional | A machine code such as `DOWNLOAD_ERROR`, used in the title only when the description has no text | Every other field (`result_id`, `location_id`, `result_url`, `call_url`, `response_time`, `response_size`, `context._result_category`, `context._result_streak`) is stored with the incident and not read for the title. ### Recovery When the call passes, APImetrics sends the same shape with `result_class` set to `PASS`. It may arrive without `context._notification`: ```json { "response_size": 1532, "location_id": "public_googleuscentral1", "result_class": "PASS", "call_id": "agpzfmFwaW1ldHJpY3NyFwsSClRlc3RTZXR1cDIYgICgyOqJ2QoM", "result_url": "http://client.apimetrics.io/tests/result/agpzfmFwaW1ldHJpY3NyGAsSC1Rlc3RSZXN1bHQzGICAwM2Q-7sKDA/", "result": "OK", "context": { "_result_category": "PASS", "_result_streak": 1 }, "result_id": "agpzfmFwaW1ldHJpY3NyGAsSC1Rlc3RSZXN1bHQzGICAwM2Q-7sKDA", "call_url": "http://client.apimetrics.io/tests/test/agpzfmFwaW1ldHJpY3NyFwsSClRlc3RTZXR1cDIYgICgyOqJ2QoM/", "response_time": 412 } ``` ## Incident title The title is APImetrics' own sentence about the fault: the lead line of `context._notification.description`, its first finding, its last finding when that is different, and the result class. HTML, links and the "View details here" sign-off are removed: ``` API Call "Checkout - Create order" has failed: We could not connect to the API. Couldn't resolve host 'api.acme-shop.com' (FAIL) API Call "Checkout - Create order" was slow: The API responded in 5.3 seconds. (SLOW) ``` Titles are capped at 200 characters by shortening the findings; the call name and the class are always kept. If the description has no list, its whole text is used. If it has no text at all, the title falls back to the result code and call name, for example `DOWNLOAD_ERROR on API Call "APImetrics: All Failures: Checkout - Create order" (FAIL)`, where the call name comes from the notification title. If `call_id` is missing, the title is the plain notification title, for example `APImetrics: All Failures: Checkout - Create order`, and Spike matches repeats and recoveries by that title. A pass is titled `API Call "" is passing again (PASS)`, or `APImetrics API call is passing again (PASS)` when the pass carries no notification. Use a [Title Remapper](/alerts/title-remapper) if you prefer a different format. ## Auto resolve An incident is matched by `call_id`. Repeat failures of the same call join the open incident instead of paging again, and a `PASS` for that `call_id` resolves it. A pass with no matching open incident is dropped. Without a `call_id`, a pass resolves the incident only when it carries the same `context._notification.title` as the failure that opened it; a pass without a notification title cannot be matched and leaves the incident for you to resolve. {% hint style="warning" %} A call runs from several APImetrics locations, but the incident is identified by the call alone. A pass from one location can resolve an incident that is still failing from another, and the next failure opens it again. {% endhint %} {% hint style="success" %} This integration auto resolves {% endhint %} # Integrate Spike with App Optics Connect AppOptics to Spike via webhook so application performance alerts reach your on-call team in real time. ### Service and integration Make sure to add the App Optics integration and copy the webhook. {% content-ref url="/pages/-Ln3rb4wLUFeI-OAPcmq" %} [Create integration and service on our dashboard](/integrations-guideline/create-integration-and-service-on-dashboard) {% endcontent-ref %} ### Using webhooks with App Optics **Step 1** From the dashboard navigate to **organization settings** and then go to **notification services**. Select webhooks from the available integrations. ![](https://1743514643-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Ln3jS1bJTTsE3yoEcOu%2Fuploads%2Fgit-blob-70f98328b9d49ce6cecf35289c2b30bc045aa558%2FGroup%2043.png?alt=media) **Step 2** Paste the Spike webhook URL and save. ![](https://1743514643-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Ln3jS1bJTTsE3yoEcOu%2Fuploads%2Fgit-blob-460e8fdf5c1b8aacac454a3ba5d613b65fbe5df1%2FGroup%2044.png?alt=media) {% hint style="success" %} This integration auto resolves. {% endhint %} # Integrate Spike with AppDynamics Send AppDynamics alerts to Spike via webhook so application performance issues reach your on-call team instantly. ### Service and Integration Make sure to add the AppDynamics integration and copying the webhook. {% content-ref url="/pages/-Ln3rb4wLUFeI-OAPcmq" %} [Create integration and service on our dashboard](/integrations-guideline/create-integration-and-service-on-dashboard) {% endcontent-ref %} ### Using webhooks with AppDynamics #### Step 1 From the dashboard, go to the Alert & Respond menu. ![](https://1743514643-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Ln3jS1bJTTsE3yoEcOu%2Fuploads%2Fgit-blob-1af791bf0fcdb86c9be39b251011c2cbef25ef65%2Fimage%20$98$.png?alt=media\&token=db73a770-9584-4fd3-ab95-c7ccf2284e96) #### #### Step 2 Select HTTP Request Templates. ![](https://1743514643-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Ln3jS1bJTTsE3yoEcOu%2Fuploads%2Fgit-blob-6b6c48b9d0b11ba26d6ca67296d47bbc9a81647a%2Fimage.png?alt=media\&token=f9ea1c05-872a-4241-95d1-149e2f0d19ea) #### #### Step 3 Add a Custom Templating Variable named `sc_event_type` and the default value as `triggered`.\ Paste the Spike webhook URL ![](https://1743514643-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Ln3jS1bJTTsE3yoEcOu%2Fuploads%2Fgit-blob-070a088da6fb6582ef9c4c68074d2a9703b493b5%2Fimage%20$79$.png?alt=media\&token=f0ff2faa-f99f-4bb4-bec3-c1ff1699c59d) #### Step 4 Paste the webhook provided below and add success criteria ![](https://1743514643-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Ln3jS1bJTTsE3yoEcOu%2Fuploads%2Fgit-blob-cb714cdafcf222ab9732d79730956d302b9df7be%2Fimage.png?alt=media\&token=724e4773-13cd-4a28-9d0b-3a7f5d41efad) ``` { "description": "${latestEvent.displayName} on ${latestEvent.node.name}", "client": "AppDynamics", "client_url": "${controllerUrl}", "event_type": "${sc_event_type}", "incident_key": "${latestEvent.node.name} - ${latestEvent.application.name}", "details": { "event_name": "${latestEvent.displayName}", "message": "${latestEvent.eventMessage}", "summary": "${latestEvent.summaryMessage}", "event_id": "${latestEvent.id}", "event_time": "${latestEvent.eventTime}", "event_type_key": "${latestEvent.eventTypeKey}", "node_name": "${latestEvent.node.name}", "application_name": "${latestEvent.application.name}", "event_type": "${latestEvent.eventType}", "guid": "${latestEvent.guid}", "severity": "${latestEvent.severity}" } } ``` {% hint style="success" %} This integration auto resolves {% endhint %} # Integrate Spike with AppSignal Get real-time Phone, SMS, and Slack alerts for server, application, and performance issues with AppSignal and Spike. ## Service and integration When the bits hit the fan, developers need clear and focused insights. [AppSignal](https://appsignal.com) combines 5 powerful monitoring features into one powerful APM. {% content-ref url="/pages/-Ln3rb4wLUFeI-OAPcmq" %} [Create integration and service on our dashboard](/integrations-guideline/create-integration-and-service-on-dashboard) {% endcontent-ref %} ## Using our webhook on AppSignal To integrate our webhook on AppSignal, visit their dashboard and go to the "Notifications" tab the site's sidebar, click the "Add integration" and paste the webhook you copied from Spike ![Select your events on AppSignal](https://1743514643-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Ln3jS1bJTTsE3yoEcOu%2Fuploads%2Fgit-blob-c2b43d77687a61d5d4714086cfc7f243d2bd2f16%2F1.png?alt=media\&token=3f60123e-be19-4ff4-952c-4d37375a80fc) Give an appropriate name on AppSignal as it might appear in alerts for some cases. {% hint style="success" %} Only alerts (anomaly detection) incidents will **auto-resolve**. {% endhint %} # Integrate Spike with AppViewX Send AppViewX certificate expiry alert emails to Spike so an expiring certificate pages your on-call rotation by phone, SMS, Slack or Teams. [AppViewX](https://www.appviewx.com) manages the certificates your organisation relies on. It emails an expiry alert when a certificate is about to expire, so someone can renew it before a site or service breaks. AppViewX alerts are emails, so the Spike AppViewX integration has an email address instead of a webhook URL. Add that address as a recipient of the AppViewX expiry alert and each alert pages your on-call rotation instead of waiting in a mailbox. ## What Spike does with each email | What AppViewX sends | What Spike does | | ---------------------------------------------------------------------- | ---------------------------------------------- | | Expiry alert for a certificate | Opens an incident and pages | | The same alert again for the same certificate (the next scheduled run) | Adds to the incident already open, no new page | | A 0-10 day "Critical" alert whose body matches the routine one | Adds to the incident already open, no new page | AppViewX sends no recovery email, so Spike cannot resolve these incidents on its own. Resolve the incident in Spike once the certificate is renewed. {% hint style="info" %} The incident title is the email body as AppViewX wrote it, with links removed and whitespace tidied, up to 200 characters. With the recommended template that reads **Certificate with Common Name shop.acme.com Serial number 0A1B2C3D4E5F60718293A4B5C6D7E8F9 issued by DigiCert Global G2 TLS RSA SHA256 2020 CA1 is about to expire on 11/07/2026**. When the body is empty the subject is the title. The full email is kept in the incident details. {% endhint %} ## Set up the integration ### Step 1: Create the integration in Spike From the header, click [Add integration](https://app.spike.sh/integrations/new), select **AppViewX**, give it a name and create the integration. ### Step 2: Copy the email address Copy the unique email address from the integration page. It looks like `9f3c2a71be04d58e6a17@email-hooks.spike.sh`. ### Step 3: Make sure AppViewX can send email AppViewX sends alerts through your organisation's mail server. If AppViewX already emails your team, nothing changes here; otherwise ask your AppViewX administrator to set up outbound email. The sender they configure is what Spike shows as `from` in the incident details. ### Step 4: Create an expiry alert that emails Spike Your AppViewX role needs **Expiry Alerts** enabled under **Authorized Functions > CLM**, and its resource needs the **Cert\_Expiry\_Mail\_Individual** and **Cert\_Expiry\_Mail\_Bulk** workflow requests (**Access Control > Workflow Requests**). 1. Go to **Menu > CLM > ALERTS & LOGS > Expiry Alerts** and click **+ Create**. 2. Enter an **Alert Name**, then under **Alert Configuration** click **+ Add**. 3. Choose the **Certificate Type** and the **Certificate Expiry Period** the alert covers. 4. Set **Notification Method** to **Email** and turn on **Individual Alerts**, so each certificate gets its own email and its own incident. Turning on **Ignore renewed/regenerate certificate** stops alerts for a certificate once it is renewed. 5. Under **Email Configuration**, put the Spike address in **To** (keep any existing recipients), and use AppViewX's recommended subject and body: ``` Subject: Expiry Alert :: |Common Name| certificate| expiring on |Valid Until| Certificate with Common Name |Common Name| Serial number |Serial Number| issued by |Issuer Common Name| is about to expire on |Valid Until| ``` 6. Click **Add**, choose **Schedule** (daily is typical) as the **Alert Execution Type**, and click **Save**. The body becomes the incident title, and the scheduled run sends the same body about the same certificate each time, so the repeats join one incident. ### Step 5: Test it Run the alert with **Run Now**, or wait for the next scheduled run, and check that an incident appears in Spike. ## What AppViewX sends Spike receives the email as these fields: ```json { "to": "9f3c2a71be04d58e6a17@email-hooks.spike.sh", "from": "AppViewX Alerts ", "subject": "Expiry Alert :: shop.acme.com certificate is expiring on 11/07/2026", "text": "Certificate with Common Name shop.acme.com\nSerial number 0A1B2C3D4E5F60718293A4B5C6D7E8F9\nissued by DigiCert Global G2 TLS RSA SHA256 2020 CA1\nis about to expire on 11/07/2026\n", "html": "

Certificate with Common Name shop.acme.com
Serial number 0A1B2C3D4E5F60718293A4B5C6D7E8F9
issued by DigiCert Global G2 TLS RSA SHA256 2020 CA1
is about to expire on 11/07/2026

", "envelope": "{\"to\":[\"9f3c2a71be04d58e6a17@email-hooks.spike.sh\"],\"from\":\"appviewx-alerts@acme.com\"}" } ``` | Field | Required | Used for | | ---------- | -------- | ------------------------------------------------------------------------------------- | | `to` | Yes | The part before `@` selects your integration | | `envelope` | No | Its `to` list is also matched, so forwarded mail still reaches the integration | | `subject` | No | The title when the body is empty, and always kept in the details | | `text` | No | The plain-text body, which is the title | | `html` | No | Converted to text and used as the title when `text` is empty, and kept in the details | | `from` | No | Kept in the details | If the email has no usable subject or body, the incident is titled **AppViewX alert with no details**. ## Good to know {% hint style="warning" %} * Spike matches repeats on the title, so keep the body free of values that change between runs, such as a run timestamp. A changed body opens a new incident. * Individual alerts include renewal and unsubscribe links. The links are removed from the title, but their text (for example "Renew certificate") stays in it. * Bulk-mode alerts send the certificate list as an attachment. When their body is empty the title is the subject, for example **Expiry Alert :: Certificates expiring in next 30 days**. {% endhint %} # Integrate Spike with Argo CD Send Argo CD notifications to Spike so a failed sync or an unhealthy application pages your on-call rotation, and the incident resolves when the app is healthy and synced again. [Argo CD](https://argo-cd.readthedocs.io) is a declarative GitOps continuous delivery tool for Kubernetes. It keeps each Application in your cluster matched to the Git revision it points at, and reports when a sync fails or the application stops being healthy. Argo CD Notifications can post to any webhook. Point one at a Spike integration URL and a failed sync or a degraded application pages your on-call rotation, repeats join the incident already open, and the incident resolves itself when Argo CD reports the application healthy and synced. Nothing is installed in your cluster. The setup is one webhook service, two templates and two triggers in the `argocd-notifications-cm` ConfigMap, plus a subscription on the applications you want to watch. ## How Spike reads a notification Spike reads the `status` field you type into each template and the Application's UID. | `status` | What Spike does | | ------------------------- | ---------------------------------------------------------------------------------------------- | | `firing` | Opens an incident, or joins the open one for the same `app_uid` | | `resolved` | Resolves the open incident with the same `app_uid`. With nothing open, the recovery is dropped | | Anything else, or missing | Treated as `firing`. Spike never resolves on it | `operation_phase`, `health_status` and `sync_status` only choose the wording of the title. They never open or close anything. ## Incident identity Spike identifies the incident by `app_uid`, the Application's Kubernetes UID. It is stable for the Application's whole life, so repeats join the incident already open and the recovery resolves it. The title is for reading only. `app_uid` counts only when it is a non-empty string (or a number) and not an unexpanded template: ``, anything containing `{{` or `}}`, or a whole value like `$app_uid`, `${app_uid}` or `%app_uid%`. Without a usable `app_uid`, Spike matches the open incident by title instead of by `app_uid`, so repeats of the same alert for the same application still join one incident. The title is then the plain one with no Argo CD sentence in it: a failed sync reads `Sync failed on {app}` on every retry, however `operation_message` changes. ## Incident title | Event | Title | | -------------------------------------------------------------------------------------- | --------------------------------- | | `operation_phase` `Failed` or `Error`, with `operation_message` and a usable `app_uid` | `{operation_message} on {app}` | | `operation_phase` `Failed` or `Error`, any other case | `Sync failed on {app}` | | `health_status` `Degraded`, `Missing` or `Unknown` | `Health {health_status} on {app}` | | `sync_status` `Unknown` | `Sync status Unknown on {app}` | | Anything else | `Argo CD alert on {app}` | | `status` `resolved` | `{app} is synced and healthy` | With no usable `app`, `on {app}` is left off (`Sync failed`, `Argo CD application is synced and healthy`), and with nothing usable the title is `Argo CD alert with no details`. Whitespace in the sentence is collapsed, and `on {app}` is left off when the sentence already names the application as a whole word. Titles are capped at 200 characters: `on {app}` is kept whole and the sentence is cut at a word boundary with `...`. Revisions, URLs and timestamps are never in the title. Argo CD may change `operation_message` between deliveries (for example by appending `(retried 2 times)`). That is fine: the `app_uid` is what joins them. ## Severity Spike does not read a severity from the Argo CD payload, so incidents open at your integration's default. Use an [alert rule](/alerts/alert-rules) on `health_status`, `project` or `app` to set severity, route to another service or suppress. Read more about [priority and severity](/incidents/priority-and-severity). ## Prerequisites * Argo CD with the Notifications controller running (bundled with Argo CD 2.3 and later) * Permission to edit the `argocd-notifications-cm` ConfigMap and to annotate Applications or AppProjects * An Argo CD integration in Spike and its webhook URL * Nothing to open on your network. Argo CD calls out to Spike, so your cluster needs outbound HTTPS to `hooks.spike.sh` ## Step 1 — Create the integration in Spike In Spike, go to **Integrations → Add integration → Argo CD**, attach it to a service and an escalation policy, and copy the webhook URL. It looks like `https://hooks.spike.sh//push-events`. {% content-ref url="/pages/-Ln3rb4wLUFeI-OAPcmq" %} [Create integration and service on our dashboard](/integrations-guideline/create-integration-and-service-on-dashboard) {% endcontent-ref %} ## Step 2 — Store the webhook URL in Argo CD The URL contains your token, so keep it in the `argocd-notifications-secret` Secret rather than in the ConfigMap: ```bash kubectl -n argocd patch secret argocd-notifications-secret \ --type merge -p '{"stringData": {"spike-url": "https://hooks.spike.sh//push-events"}}' ``` If you manage the Secret declaratively, add a `spike-url` key to it instead. ## Step 3 — Add the service, templates and triggers Argo CD has no screen for notifications; they are configured in the `argocd-notifications-cm` ConfigMap. Edit it (`kubectl -n argocd edit configmap argocd-notifications-cm`) and add the following. Argo CD has no variable that says which trigger fired, so the `status` value is typed into each template as a literal. `{{.context.argocdUrl}}` needs the `context` entry shown. ```yaml data: context: | argocdUrl: https://argocd.example.com service.webhook.spike: | url: $spike-url headers: - name: Content-Type value: application/json template.spike-firing: | webhook: spike: method: POST body: | { "status": "firing", "app": {{ .app.metadata.name | toJson }}, "app_uid": {{ .app.metadata.uid | toJson }}, "app_namespace": {{ .app.metadata.namespace | toJson }}, "project": {{ .app.spec.project | toJson }}, "health_status": {{ .app.status.health.status | toJson }}, "sync_status": {{ .app.status.sync.status | toJson }}, "operation_phase": {{ if .app.status.operationState }}{{ .app.status.operationState.phase | toJson }}{{ else }}""{{ end }}, "operation_message": {{ if .app.status.operationState }}{{ .app.status.operationState.message | toJson }}{{ else }}""{{ end }}, "revision": {{ .app.status.sync.revision | toJson }}, "destination_server": {{ .app.spec.destination.server | toJson }}, "destination_namespace": {{ .app.spec.destination.namespace | toJson }}, "finished_at": {{ if .app.status.operationState }}{{ .app.status.operationState.finishedAt | toJson }}{{ else }}""{{ end }}, "app_url": "{{ .context.argocdUrl }}/applications/{{ .app.metadata.name }}" } template.spike-resolved: | webhook: spike: method: POST body: | { "status": "resolved", "app": {{ .app.metadata.name | toJson }}, "app_uid": {{ .app.metadata.uid | toJson }}, "app_namespace": {{ .app.metadata.namespace | toJson }}, "project": {{ .app.spec.project | toJson }}, "health_status": {{ .app.status.health.status | toJson }}, "sync_status": {{ .app.status.sync.status | toJson }}, "operation_phase": {{ if .app.status.operationState }}{{ .app.status.operationState.phase | toJson }}{{ else }}""{{ end }}, "operation_message": {{ if .app.status.operationState }}{{ .app.status.operationState.message | toJson }}{{ else }}""{{ end }}, "revision": {{ .app.status.sync.revision | toJson }}, "destination_server": {{ .app.spec.destination.server | toJson }}, "destination_namespace": {{ .app.spec.destination.namespace | toJson }}, "finished_at": {{ if .app.status.operationState }}{{ .app.status.operationState.finishedAt | toJson }}{{ else }}""{{ end }}, "app_url": "{{ .context.argocdUrl }}/applications/{{ .app.metadata.name }}" } trigger.on-spike-sync-failed: | - when: app.status.operationState != nil and app.status.operationState.phase in ['Error', 'Failed'] send: [spike-firing] oncePer: app.status.operationState.finishedAt trigger.on-spike-health-degraded: | - when: app.status.health.status in ['Degraded', 'Missing', 'Unknown'] send: [spike-firing] trigger.on-spike-sync-status-unknown: | - when: app.status.sync.status == 'Unknown' send: [spike-firing] trigger.on-spike-resolved: | - when: app.status.health.status == 'Healthy' and app.status.sync.status == 'Synced' send: [spike-resolved] ``` Send the body exactly as shown, field for field. This is what a failed sync looks like once rendered: ```json { "status": "firing", "app": "checkout-prod", "app_uid": "6f1c2b7e-9d4a-4c8e-b3a1-2e5f7d9c0a14", "app_namespace": "argocd", "project": "payments", "health_status": "Healthy", "sync_status": "OutOfSync", "operation_phase": "Failed", "operation_message": "one or more objects failed to apply, reason: Deployment.apps \"checkout\" is invalid: spec.template.spec.containers[0].image: Required value", "revision": "a3f9c1d27be84e0f5c6d9b21e7a4f0c8d3b5e6a1", "destination_server": "https://kubernetes.default.svc", "destination_namespace": "checkout", "finished_at": "2026-10-14T03:12:44Z", "app_url": "https://argocd.example.com/applications/checkout-prod" } ``` And the recovery, once the application is healthy and synced again: ```json { "status": "resolved", "app": "checkout-prod", "app_uid": "6f1c2b7e-9d4a-4c8e-b3a1-2e5f7d9c0a14", "app_namespace": "argocd", "project": "payments", "health_status": "Healthy", "sync_status": "Synced", "operation_phase": "Succeeded", "operation_message": "successfully synced (all tasks run)", "revision": "c71e0b94f2d35a8e6b1c4f07d9a2e5b8f3c6d1a0", "destination_server": "https://kubernetes.default.svc", "destination_namespace": "checkout", "finished_at": "2026-10-14T03:41:09Z", "app_url": "https://argocd.example.com/applications/checkout-prod" } ``` | Field | Used for | | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------ | | `status` | **Required.** `firing` or `resolved`, typed as a literal in each template | | `app_uid` | **Required for joining and resolving.** The incident's identity; see [Incident identity](#incident-identity) | | `app` | **Required.** The application name at the end of every title | | `operation_message` | The sentence in a sync failure title, when `operation_phase` is `Failed` or `Error` and `app_uid` is usable | | `operation_phase` | `Failed` or `Error` selects the sync failed title | | `health_status` | `Degraded`, `Missing` or `Unknown` selects the health title | | `sync_status` | `Unknown` selects the sync status title | | `app_namespace`, `project`, `revision`, `destination_server`, `destination_namespace`, `finished_at`, `app_url` | Incident details only | {% hint style="warning" %} Do not add a top-level `message` key to the body. Spike would use it as the incident title and skip the Argo CD parser, so titles, the recovery title and the id rules above would no longer apply. {% endhint %} {% hint style="warning" %} `operationState` does not exist until the first sync, so the template guards the `operation_*` and `finished_at` fields with `{{ if .app.status.operationState }}`. A field Argo CD cannot fill may arrive as ``; Spike treats that as missing. Check the rendered body with a test notification (Step 5) before relying on it. {% endhint %} ## Step 4 — Subscribe your applications Subscriptions are annotations. Add them to a single Application, or to an AppProject to cover every Application in it: ```bash kubectl -n argocd annotate application checkout-prod \ notifications.argoproj.io/subscribe.on-spike-sync-failed.spike="" \ notifications.argoproj.io/subscribe.on-spike-health-degraded.spike="" \ notifications.argoproj.io/subscribe.on-spike-sync-status-unknown.spike="" \ notifications.argoproj.io/subscribe.on-spike-resolved.spike="" ``` The part after `subscribe.` is the trigger name and the last part, `spike`, is the webhook service from Step 3. The value stays empty because a webhook service has no recipient. {% hint style="info" %} Always subscribe the recovery trigger with the failure triggers. Without `on-spike-resolved`, Spike opens incidents and nothing resolves them until somebody does it by hand. A [resolve timer](/incidents/resolve-timer) is a reasonable backstop. The recovery is a custom trigger because the catalogue's `on-deployed` fires once per revision, so a health recovery without a new commit would not be reported. {% endhint %} {% content-ref url="/pages/-MRcwUUCSJO-4crz5xXn" %} [Archive an integration](/integrations-guideline/archive-an-integration) {% endcontent-ref %} ## Step 5 — Confirm it end to end 1. Send a test notification from the CLI: ```bash argocd admin notifications template notify spike-firing checkout-prod \ --recipient spike ``` 2. Check the incident that opens in Spike. Its page shows the application name, UID, phase and health status. 3. Break a sync on purpose (for example a manifest with a missing required field) and look for an incident titled with the sync error and your application name. 4. Fix the manifest, sync again, and watch the incident resolve; its last event is titled ` is synced and healthy`. ## Things worth knowing * **One service covers every application.** Add the webhook service once; subscribe as many Applications or projects as you like. * **Each fault has its own trigger.** A trigger without `oncePer` sends once each time its condition goes from false to true. Keeping sync failure, health and sync status in separate triggers means a new fault still sends while another is active, for example a failed sync on an application that is already `Degraded`. `on-spike-sync-failed` uses `oncePer` on the operation's `finishedAt`, so each failed operation notifies once. * **Resolving in Spike does not touch Argo CD.** The Application keeps its status; the next failure opens a fresh incident. ## Troubleshooting

Nothing arrives in Spike

Check that the Application carries the `notifications.argoproj.io/subscribe...` annotations, that the trigger names match the ConfigMap, and that `spike-url` exists in `argocd-notifications-secret`. The notifications controller logs each delivery and each failure: `kubectl -n argocd logs deploy/argocd-notifications-controller`.

The webhook body is not valid JSON

Every string value in the template ends in `| toJson`, which quotes strings safely. A value added without it breaks the JSON as soon as Argo CD renders a message containing a quote or a newline.

Incidents never resolve

Check that `on-spike-resolved` is subscribed, that its template sends `"status": "resolved"`, and that the rendered body carries the same `app_uid` as the incident that opened.

An incident titled "Argo CD alert with no details" opened

The body reached Spike without an application name or any state Spike recognises. Open the payload on the incident page and compare it with the template in Step 3.

Disclaimer: These integration instructions are offered independently by Spike.sh, and Spike.sh is not affiliated with nor a partner of the Argo Project or the Linux Foundation. # Integrate Spike with Asana Turn an Asana task into a Spike incident, and resolve the incident when the task is marked complete, by forwarding the task from Zapier, Make or a script. [Asana](https://asana.com) is a work management platform where teams track tasks and projects. Many teams file a task when something is wrong in production, and the task is completed when it is fixed. With this integration, a task that is forwarded to Spike opens an incident, and the incident resolves when the same task is forwarded again as completed. The incident title is the task name, so write the task name as a sentence about what is wrong. {% hint style="warning" %} Asana does not send this request by itself. Native Asana webhooks are **not supported**: Asana's webhook handshake needs the `X-Hook-Secret` header echoed back, which the Spike webhook URL does not do. Asana's events are also compact. They name the task that changed but not whether it is completed, and Asana expects you to fetch the task for its details. Instead, use an automation tool (Zapier, Make or your own script) to send the task to Spike. {% endhint %} ## What Spike does with each request Spike identifies a task by `gid`. Send the task fields at the top level of the body. | Request | What Spike does | | ------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------- | | `completed` is `false`, missing, or any value not listed in the next row | Opens an incident, or joins the open incident with the same `gid`, or reopens a resolved one. | | `completed` is `true`, `1`, `"true"`, `"1"` or `"yes"` | Resolves the open incident with the same `gid`. A completion never opens an incident. | Some no-code tools send every value as text, so `completed` counts as completed when it is the boolean `true`, the number `1`, or the text `"true"`, `"1"` or `"yes"` in any case, ignoring surrounding spaces. Anything else, such as `false`, `0`, `"false"` or `"no"`, opens an incident. A repeat of the same task that changes only `modified_at`, `notes`, `assignee.name`, `assignee.gid` or `priority` joins the open incident. ### Incident titles | Request | Title | | ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | Open | `` | | Open, `name` empty | `Asana task in `, or `Asana task with no details` when there is no project either | | Completed | ` marked complete`; with no name, `Asana task in marked complete`, or `Asana task marked complete` when there is no project either | For example, `Checkout API returning 502 errors for EU customers`, and on completion `Checkout API returning 502 errors for EU customers marked complete`. * Whitespace in the name is collapsed, and the name is cut at a word so that the title is at most 200 characters. On a completion the name is cut so that `marked complete` stays whole within 200. * A completion also carries the open title, so a completion without a usable `gid` resolves an open incident with the same name that was also opened without a usable `gid`. A completion without a `gid` never closes an incident whose task sent one. * The title never holds a gid, URL, timestamp, note, assignee or priority. A usable `gid` is a number other than `0`, or text that is not empty after trimming, is not an unexpanded template variable such as `$gid`, `${gid}`, `{{gid}}`, `{{1.gid}}`, `%gid%` or ``, and is not a word such as `null` or `undefined`. Spike matches the value as sent, ignoring surrounding spaces. Without a usable `gid`, Spike matches on the title, and only against incidents that were also opened without one. ## Fields | Field | Required | Used for | | ------------------ | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | | `gid` | Yes | The Asana task id. Matches the completion to the incident that the task opened. Send it as a quoted string: 16-digit ids lose precision as JSON numbers. | | `completed` | Yes | `false` opens an incident, `true` resolves it | | `name` | Yes | The title | | `projects[0].name` | No | The fallback title `Asana task in ` when `name` is empty | | `priority` | No | Your own value for a "Priority" custom field. Not an Asana task field; Spike lifts a top-level `priority` onto the incident | | `permalink_url` | No | Added to the incident as a link to the task | `resource_type`, `notes`, `completed_at`, `created_at`, `modified_at` and `assignee.name` are kept on the incident for your team to read, but Spike does not act on them. ## Prerequisites * An Asana account that can view the tasks you want to forward * An account on Zapier or Make, or a script that can send an HTTP `POST` request * An Asana integration in Spike and its webhook URL ## Step 1 — Create the integration in Spike In Spike, go to **Integrations → Add integration → Asana**, attach it to a service and an escalation policy, and copy the webhook URL. It looks like `https://hooks.spike.sh//push-events`. {% content-ref url="/pages/-Ln3rb4wLUFeI-OAPcmq" %} [Create integration and service on our dashboard](/integrations-guideline/create-integration-and-service-on-dashboard) {% endcontent-ref %} ## Step 2 — Send the task from your automation tool Create two automations, one for a new task and one for a completed task. Both send a `POST` request with a JSON body to the webhook URL from Step 1. Let your tool build the JSON from fields you map. Do not paste mapped values into JSON you write by hand. Task names often contain quotes, and notes often contain line breaks. Pasted unescaped, they make the body invalid JSON. Spike then rejects the request and no incident opens. ### Zapier 1. **Trigger.** Choose the **Asana** app. Use **New Task** for the first Zap and **Completed Task** for the second. 2. **Action.** Add **Webhooks by Zapier** with the **POST** event. Set **URL** to your Spike webhook URL and **Payload Type** to `json`. 3. **Data.** Add one row per field and map each value from the Asana trigger: | Key | Value | | ---------------- | --------------------------------------------------------------------- | | `gid` | The task's gid (ID) | | `name` | The task name | | `completed` | Type `false` in the New Task Zap and `true` in the Completed Task Zap | | `permalink_url` | The task's permalink URL | | `notes` | The task notes | | `assignee__name` | The assignee's name | Zapier encodes these values for you. A double underscore in a key nests the value, so `assignee__name` arrives as `"assignee": {"name": …}`. Zapier sends every value as text, which Spike accepts: the gid arrives as a quoted string, and `"true"` resolves the incident. Do not use **Custom Request** for this. It sends the **Data** box exactly as you type it and does not escape mapped values, so a task name with a `"` or notes with a line break produce invalid JSON. Custom Request adds only one thing: a `projects` array, which Spike uses for the `Asana task in ` title when a task has no name. If you need that, first pass `name` and `notes` through a Formatter step that escapes quotes and line breaks, or leave `notes` out. ### Make 1. **Trigger.** Start the first scenario with **Asana → Watch New Tasks**. Start the second with **Asana → Watch Tasks or Subtasks**, and set **Watch** to completed tasks. 2. **Action.** Add **HTTP → Make a request**. Set **URL** to your Spike webhook URL, **Method** to `POST`, **Body content type** to `application/json`, and **Body input method** to **Data structure**. 3. **Data structure.** Add the keys of the body below (`gid`, `name`, `notes`, `completed`, `permalink_url`, an `assignee` collection with `name`, and a `projects` array of collections with `name`), and map each one from the Asana module. Make escapes quotes and line breaks in mapped values. Avoid the **JSON string** input method, which sends mapped values unescaped. ### A script `POST` the body below with the header `Content-Type: application/json`. Build it with your language's JSON encoder, for example `JSON.stringify` or `json.dumps`, not by joining strings. ### The body Spike reads Send `completed: false` from the new-task automation and `completed: true` from the completed-task automation. If a variable is left unexpanded, Spike treats it as missing. A task body that opens an incident: ```json { "gid": "1209876543210123", "resource_type": "task", "name": "Checkout API returning 502 errors for EU customers", "notes": "Error rate on checkout-api in eu-west-1 jumped to 12% at 02:10 UTC. Card payments are failing for EU customers.", "completed": false, "completed_at": null, "created_at": "2026-10-13T02:14:07.512Z", "modified_at": "2026-10-13T02:14:07.512Z", "permalink_url": "https://app.asana.com/1/1201234567890001/project/1209876543200001/task/1209876543210123", "assignee": { "gid": "1201234567890456", "name": "Priya Raman" }, "projects": [ { "gid": "1209876543200001", "name": "Production Incidents" } ], "priority": "High" } ``` The same task when it is completed, which resolves the incident: ```json { "gid": "1209876543210123", "resource_type": "task", "name": "Checkout API returning 502 errors for EU customers", "notes": "Error rate on checkout-api in eu-west-1 jumped to 12% at 02:10 UTC. Card payments are failing for EU customers. Rolled back release 2026.10.12-3; error rate back to 0.1%.", "completed": true, "completed_at": "2026-10-13T03:02:41.208Z", "created_at": "2026-10-13T02:14:07.512Z", "modified_at": "2026-10-13T03:02:41.208Z", "permalink_url": "https://app.asana.com/1/1201234567890001/project/1209876543200001/task/1209876543210123", "assignee": { "gid": "1201234567890456", "name": "Priya Raman" }, "projects": [ { "gid": "1209876543200001", "name": "Production Incidents" } ], "priority": "High" } ``` From Make or a script, send `completed` as `false` or `true` without quotes, and quote `gid`. Spike also accepts `completed` as text, as Zapier sends it. Without `projects`, as from a Zapier **POST**, the incident still works. Only the `Asana task in ` title for a task with no name is lost. ## Step 3 — Test it 1. In Asana, create a task named like the example, in the project your automation watches. 2. Once your Zapier or Make plan's polling interval has passed, an incident titled `Checkout API returning 502 errors for EU customers` should open in Spike. 3. Mark the task complete in Asana. The incident resolves, and an event titled `Checkout API returning 502 errors for EU customers marked complete` appears on it. ## Good to know * **Rename the task before it is completed** and the completion still resolves the right incident, because Spike matches on `gid`. If your tool does not send a usable `gid`, Spike matches on the title instead, so the name must not change in between, or the incident stays open. Send the `gid` from both automations: a completion without one never closes an incident whose task sent one. * **Severity** is not read from Asana. Use an [alert rule](/alerts/alert-rules) to set severity, route to another service, or suppress incidents from certain projects. * Spike groups repeats of the same task and suppresses new alerts while its incident is open. # Integrate Spike with Assertible Create incidents in Spike from Assertible test run alerts, and resolve them when the tests pass again, by email. [Assertible](https://assertible.com) runs automated tests against your web services and APIs. Assertible sends alerts through an email hook, so the Spike Assertible integration has an email address instead of a webhook URL. ## How does the Assertible integration work? * When an Assertible email says a test run **failed**, Spike creates an incident. * The incident title is the first line of the email's plain-text body, which is Assertible's own sentence about what failed. * When an email says the tests **passed** for the same alert, Spike resolves the incident. Spike matches the two emails by their subject with the words failed/failing/passed/passing removed. A passing email with no incident open for it is dropped. * An email that says neither is treated as a failure and opens an incident. * An email without a usable subject is matched on its title instead, and never resolves itself. {% hint style="info" %} The Assertible subject and body wording has not been verified against a real capture. If Assertible does not send an email when tests pass again, the incident has to be resolved manually in Spike. {% endhint %} ## Setup ### Step 1: Create the integration in Spike From the header > click [Add integration](https://app.spike.sh/integrations/new), select **Assertible**, give it a name and create the integration. ### Step 2: Copy the email address Copy the email address from the integration page. It looks like `9f3c2a7e41b8d05c6e12@email-hooks.spike.sh`. ### Step 3: Add an email hook in Assertible 1. Open your web service in Assertible and go to its **Settings**, then the **Hooks & Alerts** tab. 2. Add an **Email** hook and paste the Spike email address into **Send email to**. 3. Under **Send email when**, pick **On test run complete** if you want incidents to resolve themselves: it emails every run, passing ones included. **On test run failure** emails only failing runs, so you resolve those incidents by hand in Spike. 4. Optionally limit **When tests are run via** (Deployments, Schedules, Trigger URL, Dashboard). 5. Enable the tests that should alert on the hook. Assertible does not enable new tests on existing hooks by default. 6. Save. Required: the Spike email address. Spike does not filter on the sender address. ### Step 4: Test it Trigger a test run in Assertible, or send a test email to the Spike address, and check that an incident is created. ## Example email Spike receives each email as the following fields. A failing run: ```json { "to": "9f3c2a7e41b8d05c6e12@email-hooks.spike.sh", "from": "Assertible ", "subject": "[Assertible] Test run failed: Orders API (production)", "text": "1 of 4 tests failed for Orders API in production.\n\nFAILED GET /v1/orders - status code: expected 200, got 503\nPASSED GET /v1/health\nPASSED POST /v1/orders\nPASSED GET /v1/orders/{id}\n\nView the test run in Assertible.", "html": "

1 of 4 tests failed for Orders API in production.

FAILED GET /v1/orders - status code: expected 200, got 503
PASSED GET /v1/health
PASSED POST /v1/orders
PASSED GET /v1/orders/{id}

View the test run in Assertible.

", "envelope": "{\"to\":[\"9f3c2a7e41b8d05c6e12@email-hooks.spike.sh\"],\"from\":\"notifications@assertible.com\"}" } ``` A passing run, which resolves the incident: ```json { "to": "9f3c2a7e41b8d05c6e12@email-hooks.spike.sh", "from": "Assertible ", "subject": "[Assertible] Test run passed: Orders API (production)", "text": "All 4 tests passed for Orders API in production.\n\nPASSED GET /v1/orders\nPASSED GET /v1/health\nPASSED POST /v1/orders\nPASSED GET /v1/orders/{id}\n\nView the test run in Assertible.", "html": "

All 4 tests passed for Orders API in production.

PASSED GET /v1/orders
PASSED GET /v1/health
PASSED POST /v1/orders
PASSED GET /v1/orders/{id}

View the test run in Assertible.

", "envelope": "{\"to\":[\"9f3c2a7e41b8d05c6e12@email-hooks.spike.sh\"],\"from\":\"notifications@assertible.com\"}" } ``` | Field | Required | Used for | | ---------- | -------- | ---------------------------------------------------------------- | | `to` | Yes | Routes the email to your integration through the address token | | `subject` | Yes | Failed or passed status, and matching a recovery to its incident | | `text` | Yes | Incident title and body (built from `html` if empty) | | `html` | No | Rich display in the incident | | `from` | No | Shown in incident details only | | `envelope` | No | Extra recipients for forwarded mail | {% hint style="warning" %} For recovery to work, the failing and passing emails for the same service and environment must have the same subject apart from the word failed/passed. There is a 30 MB payload limit. {% endhint %} # Integrate Spike with Atatus Send Atatus alert incidents to Spike so a breached threshold pages your on-call rotation by phone, SMS, Slack or Teams, and the incident resolves itself when Atatus closes it. [Atatus](https://www.atatus.com) is a full-stack observability platform covering APM, logs, infrastructure, uptime and real user monitoring. Its alerting opens an incident when an alert rule's condition is breached, and closes it when the condition returns to normal or someone closes it by hand. Atatus can post each of those moves to a webhook. Point a webhook at a Spike integration URL and an Atatus incident pages your on-call rotation when it opens, repeats of the same Atatus incident land on the incident already open instead of paging again, and the Spike incident resolves itself when Atatus closes the incident. ## What Spike does with each notification Spike reads the `status` field of every delivery. Matching ignores case and surrounding spaces. | `status` | What Spike does | | -------------- | --------------------------------------------------------------------------------------------- | | `Opened` | Opens an incident, or joins the open one with the same `incident_id` | | `Closed` | Resolves the open incident with the same `incident_id`. It never opens an incident on its own | | `Acknowledged` | Joins the open incident and never resolves it | `Resolved`, `OK` and `Cleared` are treated like `Closed`. A missing or unrecognised status opens an incident, so a notification is never silently dropped. ## Incident titles The title is Atatus's own sentence for the condition that fired, taken from `description`: ``` Response Time goes above 2000 ms ``` If `description` is empty, Spike uses `{rule_name} on {target_name}`, then `rule_name` alone when there is no target, then `alert_policy_name`. If none of them is present the title is `Atatus alert with no details`. Spaces are collapsed and titles are capped at 200 characters. A recovery is titled with the same title plus `— resolved`: ``` Response Time goes above 2000 ms — resolved ``` Matching is done on `incident_id`, not on the title, so an Opened and a Closed notification of one Atatus incident always pair up. Without an `incident_id`, Spike falls back to matching the exact title, which only works while `description` does not change between notifications. A Closed notification resolves an incident only when both carry the same `incident_id`, or neither carries one. ## Severity Spike reads the `severity` field onto the incident's severity badge: `Critical` becomes SEV1 and `Warning` becomes SEV2. Use an [alert rule](/alerts/alert-rules) on `severity` if you want a different mapping. Read more about [priority and severity](/incidents/priority-and-severity). ## Prerequisites * An Atatus account that can manage alert channels and alert policies * An Atatus integration in Spike and its webhook URL ## Step 1 — Create the integration in Spike In Spike, go to **Integrations → Add integration → Atatus**, attach it to a service and an escalation policy, and copy the webhook URL. It looks like `https://hooks.spike.sh//push-events`. {% content-ref url="/pages/-Ln3rb4wLUFeI-OAPcmq" %} [Create integration and service on our dashboard](/integrations-guideline/create-integration-and-service-on-dashboard) {% endcontent-ref %} ## Step 2 — Add a webhook in Atatus 1. **Sign in to Atatus** and open **Alerting** from the side menu. 2. **Open Alert Channels** (the Integrations / notification channels page) and choose **Webhook**. 3. **Paste the Spike webhook URL** from Step 1 into the webhook URL field, give the channel a name such as `Spike`, and save. 4. **Attach the channel to your alert policies.** Open **Alerting → Alert Policies**, edit the policy (or create one), and add the Spike webhook under its notification channels. Save the policy. Atatus sends a JSON `POST` for every incident the policy opens and closes. Menu names can differ slightly between Atatus plans; look for the webhook option under your alert channels. ## What Atatus sends An Opened notification: ```json { "incident_id": 48213, "status": "Opened", "severity": "Critical", "description": "Response Time goes above 2000 ms", "rule_name": "High response time", "rule_id": 9127, "alert_policy_name": "Checkout APM", "alert_policy_id": 3341, "product": "APM", "target_name": "checkout-service", "incident_url": "https://app.atatus.com/alerting/incidents/48213", "acknowledge_url": "https://app.atatus.com/alerting/incidents/48213/acknowledge", "alert_url": "https://app.atatus.com/alerting/policies/3341", "account_id": "a1f3c9e2", "timestamp": "2026-10-08T03:12:45Z" } ``` The Closed notification of the same incident carries the same fields with `status` set to `Closed`, plus `duration`: ```json { "incident_id": 48213, "status": "Closed", "severity": "Critical", "description": "Response Time goes above 2000 ms", "rule_name": "High response time", "rule_id": 9127, "alert_policy_name": "Checkout APM", "alert_policy_id": 3341, "product": "APM", "target_name": "checkout-service", "duration": "14 minutes", "incident_url": "https://app.atatus.com/alerting/incidents/48213", "acknowledge_url": "https://app.atatus.com/alerting/incidents/48213/acknowledge", "alert_url": "https://app.atatus.com/alerting/policies/3341", "account_id": "a1f3c9e2", "timestamp": "2026-10-08T03:26:51Z" } ``` ### Fields Spike reads | Field | Required | Used for | | ------------------- | ----------- | ----------------------------------------------------------------------------------------------- | | `status` | Yes | Opened, Closed or Acknowledged: decides whether to open, join or resolve | | `severity` | Optional | Critical or Warning: the incident's severity badge | | `incident_id` | Recommended | Pairs Opened with Closed. A number or a non-empty string. Without it Spike matches on the title | | `description` | Recommended | The incident title | | `target_name` | Optional | Added to the title fallback when `description` is empty | | `rule_name` | Optional | Title fallback when `description` is empty | | `alert_policy_name` | Optional | Title fallback when `description` and `rule_name` are empty | Every other field is kept on the incident and is available to alert rules and the [Title Remapper](/alerts/title-remapper). ## Step 3 — Test it Use the webhook's test option in Atatus if it has one, or temporarily lower a rule's threshold until it fires. The incident should appear in Spike within seconds, and resolve when the Atatus incident closes. {% hint style="info" %} Atatus does not publish a schema for its webhook body, so the field names above are the best known set. If a notification arrives with fields missing, open the incident in Spike, check the raw payload, and contact support so the integration can be adjusted. {% endhint %} # Integrate Spike with AWS Connect AWS to Spike using CloudWatch alarms and an SNS topic so infrastructure alerts trigger real-time on-call incidents. ## Service and Integration Make sure you have the service and integration already setup for AWS. Follow the link below on instructions of how to create integration and service {% content-ref url="/pages/-Ln3rb4wLUFeI-OAPcmq" %} [Create integration and service on our dashboard](/integrations-guideline/create-integration-and-service-on-dashboard) {% endcontent-ref %} ## Using the webhook on AWS {% hint style="info" %} We will create a SNS topic and add alarms on say EC2 servers which can be monitored eventually on **Cloudwatch** {% endhint %} ![](https://1743514643-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Ln3jS1bJTTsE3yoEcOu%2Fuploads%2Fgit-blob-26b1478e6272f2ab5d2058f3987e3caac716027f%2Fsimple_notification_service.png?alt=media) Login to your AWS console and head straight to [Simple Notification Service (SNS)](https://console.aws.amazon.com/sns/v3/home). ![](https://1743514643-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Ln3jS1bJTTsE3yoEcOu%2Fuploads%2Fgit-blob-59629f627338a5b55283212cd2202c19a7973542%2Fsimple_notification_service_2019-06-17_14-31-16.png?alt=media) We will create a topic in SNS which will be available across AWS services. After your subscription is made, you will be taken to the topic's detail page. **Refresh the page to make sure that the status will be confirmed for the subscription**. If that fails to happen, you can click on the topic page and ask to request confirmation. ![](https://1743514643-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Ln3jS1bJTTsE3yoEcOu%2Fuploads%2Fgit-blob-3b94dae8e39457427221a3237ca094ccc5ac2bd7%2Fcreate%20topic.png?alt=media\&token=c2ce5c46-68f8-4eb3-89f2-da5a4ef5df10) Click on **Create topic** and name your topic on the next page. ![](https://1743514643-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Ln3jS1bJTTsE3yoEcOu%2Fuploads%2Fgit-blob-cdfa347213ea2d60306e75f26cf1197c045c95b4%2Fcreate%20subscription.png?alt=media\&token=e78a8127-e363-4654-9d77-773b77d79d4a) {% hint style="success" %} A good name goes a long way. We recommend you use a name that you and your peers can easily identify. One way is to give the topic your service's name on Spike {% endhint %} ![](https://1743514643-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Ln3jS1bJTTsE3yoEcOu%2Fuploads%2Fgit-blob-40d8f442070a3776f9ecb7220e031ebd4630b4c9%2Fcreate%20subscription%20form.png?alt=media\&token=766b5df1-8948-4611-ae9c-b886cf2fd5e4) Once the topic is created, you will need to create a subscription (*this is where you paste the webhook you copied from Step 1*) Once you created a topic, you will see your topic page like this ![Create a subscription for the topic you create before this step](https://1743514643-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Ln3jS1bJTTsE3yoEcOu%2Fuploads%2Fgit-blob-47555b4ee68c77ed0c5a4124c73c262ad8f2ac41%2Fsubscrition%20create%20show.png?alt=media\&token=d798fdf2-7c59-4276-a443-98947600a81f) Select **HTTPS** as the protocol and paste the copied webhook into the endpoint and click on create subscription at the bottom. *Selecting HTTPS is mandatory.* Spike will automatically confirm the subscription for you. ![](https://1743514643-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Ln3jS1bJTTsE3yoEcOu%2Fuploads%2Fgit-blob-f9f8726d68d72e1ec86ddb224e7d06cbbd961b3f%2Fsubscription%20confirmation%20pending.png?alt=media\&token=7e2f2184-d522-4356-b0fb-7f3b6bf5a12c) {% hint style="danger" %} Make sure to **Refresh** the page on AWS {% endhint %} ![](https://1743514643-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Ln3jS1bJTTsE3yoEcOu%2Fuploads%2Fgit-blob-56956e722296cd737adc22c35ecb69fc652a2ded%2Ffinal%20aws%20sns.png?alt=media\&token=c6edc291-8867-4c9b-b33f-7e9410ca526b) If the status has not changed then inside the topic, can find the subscription. Select it and request for confirmation. ## Receiving incidents on Spike We will use the above topic to receive incidents by creating alarms on Cloudwatch. We will also dive into setting up incident alarms directly from EC2. ### Cloudwatch Navigate to [Cloudwatch](https://console.aws.amazon.com/cloudwatch/home) on your AWS console ![](https://1743514643-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Ln3jS1bJTTsE3yoEcOu%2Fuploads%2Fgit-blob-7e51c87c4fe42680469d52d2862c4c447412710f%2Fcreate%20alarm.png?alt=media\&token=bea0754f-90de-443b-9024-50c77518daf9) Select alarms and then create alarm ![](https://1743514643-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Ln3jS1bJTTsE3yoEcOu%2Fuploads%2Fgit-blob-95fbddec1ccb2fa3f6c24e0a5b273fd75eabfc75%2Fselect%20metrics.png?alt=media\&token=0ee734f4-ccf1-47d6-8499-8ff91f61df12) We recommend you select an alarm which is BAD. This will trigger and actually register a new incident. **Make sure to choose the newly created service at the bottom in the ACTIONS section.** ![](https://1743514643-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Ln3jS1bJTTsE3yoEcOu%2Fuploads%2Fgit-blob-6508bdb83bd8dc000893ed033e08b9b46dfb281b%2Fselect%20other%20metrics.png?alt=media\&token=5d7a711b-bf73-4cea-b001-32cf9bb886a5) When you click on choose metric, you might see more or less services than our dashboard and that is completely fine. Choose as and many metrics you would like. {% hint style="info" %} We recommend choosing many metrics as incidents can occur from any of the above services including billing. {% endhint %} {% hint style="success" %} This integration supports auto resolution by adding an **OK** state in all your monitors in AWS {% endhint %} ### EC2 (example) We will setup incident alerts for EC2 as an example here - ![](https://1743514643-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Ln3jS1bJTTsE3yoEcOu%2Fuploads%2Fgit-blob-adc5e20ffa55e885801ed9a65c044a227f3718fb%2Fselect%20metric%20from%20ec2.png?alt=media\&token=bca531a3-1de0-4438-8235-38871ac1d357) **Follow these steps below once you have selected instance from sidebar on EC2 -** 1. Select an instance 2. Go to Actions 3. Cloudwatch Monitoring 4. Add/Edit alarms ![](https://1743514643-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Ln3jS1bJTTsE3yoEcOu%2Fuploads%2Fgit-blob-e7a00729a3f5cf34e4d0ad20aca478c34530bc5c%2Fcreate%20alarm%20ec2%20modal.png?alt=media\&token=b24b91f0-e34d-4d9e-aea3-82027e9ff54b) ![](https://1743514643-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Ln3jS1bJTTsE3yoEcOu%2Fuploads%2Fgit-blob-707f617ee22b23dc7ea2e1e3328a965017c0ee39%2Ffinal%20ec2.png?alt=media\&token=0f06b50a-715f-408b-a7a2-2e530e4a2b80) Once you see the above popup, make sure to select the SNS topic you created in Step 2. Fill in the details for your alarm. As an example, we have created a simple alarm for when the CPU Utilization crosses 60% on our EC2 instance. ## FAQ 1. **How many services and integrations can I create on Spike?** * Unlimited 2. **How many escalation policies can I have on Spike?** * Unlimited 3. **How many SNS topics can I create on AWS?** * Unlimited. At Spike, we are working hard to integrate with all the tools your business uses. We are on a mission to help **you** identify incidents/crashes/spikes before your customers do. If you have any integration in mind and would like us to build it for you then contact us at [kaushik@spike.sh.](mailto:kaushik@spike.sh) # Integrate Spike with Axiom Integrate Spike with Axiom to receive real-time alerts via Phone calls, SMS, Slack, MS Teams, and more for anomalies found in your logs

## Overview [Axiom](https://axiom.co) is a platform that provides powerful data management and observability solutions, allowing teams to ingest, store, and query large volumes of data effortlessly. It offers seamless integration with various data sources and helps you monitor, analyze, and act on your data in real-time. Axiom’s platform is designed to scale with your needs, making it a versatile tool for organizations handling extensive data pipelines and logs. With Spike’s integration, you can receive real-time alerts for various data-driven incidents detected by Axiom, including: * **Data Ingestion Failures**: Alerts when data ingestion from sources fails, ensuring you can address potential data loss immediately. * **Query Performance Issues**: Notifications when queries take longer than expected or fail, helping you maintain the performance and reliability of your data operations. * **Anomaly Detection**: Alerts when unusual patterns or anomalies are detected in your data, enabling proactive measures to prevent potential issues. {% hint style="success" %} Auto-resolution is supported for this integration. Spike will also automatically group repeated incidents and suppress alerts while incident is open. {% endhint %} ## Set up instructions **Step 1:** Make sure to add the Axiom integration and copy the webhook. {% content-ref url="/pages/-Ln3rb4wLUFeI-OAPcmq" %} [Create integration and service on our dashboard](/integrations-guideline/create-integration-and-service-on-dashboard) {% endcontent-ref %} **Step 2:** {% tabs %} {% tab title="Setup on Axiom" %} * **1. Creating a New Monitor**: * Navigate to the 'Monitors' section in your dashboard. * Click on 'New monitor' to begin setting up your monitor. * Fill in the 'Name' field with a unique identifier for your monitor. * In the 'Description' field, provide a brief description of what the monitor aims to check. * Specify the query conditions and set the frequency of checks. * **2. Adding a Notifier**: * In the 'Notification Options' section, click on 'Manage notifiers'. * Enter a recognizable 'Name' for your notifier. * Select the 'Webhook' integration. * Paste your 'Axiom Webhook'. * Save your notifier. * **3. Linking Notifier to the Monitor**: * Return to your monitor's configuration page. * Locate the 'Notification Options' section. * Select the newly created notifier. * Save your monitor settings to finalize the setup. * **Configure the Webhook**: * Enter the details for your notification, and paste the Spike webhook URL * If you see an option for setting headers, set the `ContentType` to `"application/json"` {% endtab %} {% endtabs %} # Integrate Spike with Better Uptime Send Better Uptime alerts to Spike via webhook for instant on-call notifications the moment your services go down. ### Service and Integration Make sure to add a Buildkite integration and copy the webhook URL. {% content-ref url="/pages/-Ln3rb4wLUFeI-OAPcmq" %} [Create integration and service on our dashboard](/integrations-guideline/create-integration-and-service-on-dashboard) {% endcontent-ref %} ### Using Webhooks with Better Uptime #### Step 1 Go to **integrations** from the left menu and select **exporting data** tab. ![](https://1743514643-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Ln3jS1bJTTsE3yoEcOu%2Fuploads%2Fgit-blob-f684316c52157db4d845d08235dc04bce84ae3d3%2Fimage%20$146$%20$1$%20$1$%20$1$.png?alt=media) #### Step 2 Scroll till you find Webhooks. Click on **configure webhooks**. ![](https://1743514643-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Ln3jS1bJTTsE3yoEcOu%2Fuploads%2Fgit-blob-68c17e12e82199b65001af96fde7244888058e9a%2FGroup%2094%20$1$.png?alt=media) #### Step 3 Choose the type of webhook and add the webhook. ![](https://1743514643-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Ln3jS1bJTTsE3yoEcOu%2Fuploads%2Fgit-blob-601b88180fa5023d478c9155805126cd20208e8a%2Fimage%20$147$%20$1$.png?alt=media) #### Step 4 Paste the Spike webhook and save. ![](https://1743514643-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-Ln3jS1bJTTsE3yoEcOu%2Fuploads%2Fgit-blob-7094533408aa6f56830e1aa2aa677f4bcd7c43ce%2FGroup%2096.png?alt=media\&token=0f29ebc7-69f9-46f2-8a4e-c92526c8438a) # Integrate Spike with BitBar Send BitBar test run notification emails to your Spike integration address so a failed test run opens an incident, and a success email for the same run resolves it. [BitBar](https://bitbar.com/) (SmartBear BitBar) is a cloud testing service that runs your automated tests on real mobile devices and browsers. It can email you when a test run finishes. Spike gives your integration a dedicated email address, so a BitBar email about a failed test run opens an incident and pages whoever is on call. {% hint style="warning" %} **This guide is based on illustrated emails, not captures.** BitBar does not publish the exact wording of its notification emails. Spike reads them defensively, but check the first real email against the table below. Auto-resolve needs a subject that names the test run and a success word such as `succeeded` or `passed` in the subject or, when the subject has none, in the body. {% endhint %} ## What Spike does with each email | BitBar email | What happens in Spike | | ------------------------------------------------- | -------------------------------------------------- | | A failed, aborted, timed out or errored test run | Opens an incident and pages your escalation policy | | Another failure for the same test run and project | Added as an event to the incident already open | | A success email for the same test run and project | Resolves the open incident. It never opens one | | A failure for a different test run or project | A separate incident | | An email with no recognisable outcome word | Treated as a failure, so a failure is never missed | ## How incidents are titled The incident title is the sentence BitBar writes about the run, taken from the plain-text body of the email (or the HTML body converted to text when there is no plain-text part). Spike removes links, along with a line such as `View results:` that only introduced one, collapses whitespace and cuts the title at a word boundary to at most 200 characters. For example: `Test run Nightly regression #412 in project ShopApp Android failed: 3 of 48 tests failed on 2 of 10 devices (Samsung Galaxy S23, Google Pixel 8).` The counts in the title differ from run to run, but they never split an incident: Spike groups emails by the test run, as described below, not by title. If the email has no body, the subject is used. If it has neither, the title is `BitBar alert with no details`. ## One incident per test run Spike builds an identity for the run from the email subject: lowercased, with outcome words and the run number (`#` and its digits) removed. `Test run Nightly regression #412 in project ShopApp Android failed` and `Test run Nightly regression #413 in project ShopApp Android succeeded` therefore share the identity `test run nightly regression in project shopapp android`. The failure opens the incident and the later success resolves it. Other numbers stay in the identity, so `ShopApp Android 13` and `ShopApp Android 14` are different projects: a success in one never resolves a failure in the other. The outcome is the last outcome word in the subject, because BitBar names the run and project before the outcome. A run named `Error handling` that succeeded is therefore a success. When the subject has no outcome word, Spike reads the outcome from the body, and an email with no outcome word anywhere is treated as a failure. An email whose subject is empty, or holds nothing but a run number and an outcome word, has no identity. It gets the fixed title `BitBar test run failed`, is matched by that title, and does not auto-resolve. ## Set up the integration ### Step 1: Create the Spike integration From the header, click [Add integration](https://app.spike.sh/integrations/new), select **BitBar**, name the integration and create it. Copy the email address shown on the integration page. It looks like `3f9c1e7a2b8d4c6e9a10@email-hooks.spike.sh`. ### Step 2: Turn on email notifications in BitBar BitBar's documentation says only that email notifications are turned on and off from your user settings in BitBar Cloud. Turn them on there for test runs. BitBar's notification scopes, as its public API names them, include every test run (`TEST_RUN`) and failed test runs only (`TEST_RUN_FAILURE`): * Notify on **every test run** (failures and successes). Spike opens an incident on a failure and resolves it on the next success of the same run, so this is the setting to choose. * Notify on **failed test runs only**. Incidents then never auto-resolve, so set a [resolve timer](/incidents/resolve-timer). ### Step 3: Get BitBar's emails to the Spike address If BitBar lets you enter the recipient address, enter the Spike integration address from Step 1. Otherwise BitBar emails the address of your BitBar account; create a rule in your mail provider that forwards BitBar's notification emails (from BitBar's sender address) to the Spike integration address. Forwarding keeps the subject and body, which is all Spike reads. ### Step 4: Test it Run a test that fails in BitBar, or forward an earlier BitBar failure email to your Spike address. An incident should appear within a minute. ## What Spike reads from the email Spike receives each email as the following fields. You do not need to build this yourself; BitBar's email produces it. It is shown so you can check what arrives. Spike stores these fields, with the title and the run's identity and outcome, in the incident's details. | Field | Required | Used for | | ---------- | ----------- | ---------------------------------------------------------------------------------------------- | | `to` | Yes | Routes the email to your integration. It must contain your integration address | | `subject` | Recommended | Title fallback and the test run identity and outcome. Without it the email cannot auto-resolve | | `text` | Recommended | The incident title. If empty, the `html` body is used | | `html` | No | Used in place of `text` only when `text` is empty | | `from` | No | Shown in the incident details. Never used for matching | | `envelope` | No | Also used to route forwarded mail | ### Example: a failed test run ```json { "to": "3f9c1e7a2b8d4c6e9a10@email-hooks.spike.sh", "from": "BitBar Testing ", "subject": "Test run Nightly regression #412 in project ShopApp Android failed", "text": "Test run Nightly regression #412 in project ShopApp Android failed: 3 of 48 tests failed on 2 of 10 devices (Samsung Galaxy S23, Google Pixel 8).\n\nView results: https://cloud.bitbar.com/#testing/test-run/284731/412", "envelope": "{\"to\":[\"3f9c1e7a2b8d4c6e9a10@email-hooks.spike.sh\"],\"from\":\"noreply@bitbar.com\"}" } ``` ### Example: the run succeeds ```json { "to": "3f9c1e7a2b8d4c6e9a10@email-hooks.spike.sh", "from": "BitBar Testing ", "subject": "Test run Nightly regression #413 in project ShopApp Android succeeded", "text": "Test run Nightly regression #413 in project ShopApp Android succeeded: all 48 tests passed on 10 devices.\n\nView results: https://cloud.bitbar.com/#testing/test-run/284731/413", "envelope": "{\"to\":[\"3f9c1e7a2b8d4c6e9a10@email-hooks.spike.sh\"],\"from\":\"noreply@bitbar.com\"}" } ``` ## Limits * If the subject carries per-run text other than the run number, a success email will not match the failure and the incident stays open until the resolve timer. * There is a 30 MB payload limit on emails. # Integrate Spike with Bitbucket Pipelines Send Bitbucket Pipelines build failures to Spike so on-call is paged on phone, SMS, Slack or Teams, and incidents resolve when the pipeline goes green again. [Bitbucket Pipelines](https://bitbucket.org/product/features/pipelines) reports the outcome of every run back to the commit it built, and Bitbucket sends that outcome out as a webhook. Spike listens to those build status events, so a failed pipeline opens an incident that escalates through your on-call policy, and the next successful run of the same pipeline on the same branch closes it. You can wire this up for a single repository, or once for a whole workspace so every repository in it reports to the same Spike service. {% hint style="info" %} This integration is for **Bitbucket Cloud** (`bitbucket.org`). Bitbucket Data Center and Bitbucket Server are not supported yet. {% endhint %} ## What Spike does with each build status Bitbucket sends a build status as `repo:commit_status_created` when a run starts reporting and `repo:commit_status_updated` when it finishes. Spike handles both and reacts to the state on them: | Build state | What happens in Spike | | ------------ | ---------------------------------------------------------------------------------------------------- | | `FAILED` | Opens an incident for that repository, branch and pipeline, or adds an event to the one already open | | `SUCCESSFUL` | Auto-resolves the open incident. Dropped when nothing is open | | `INPROGRESS` | Ignored. A run that is still going never pages anyone | | `STOPPED` | Ignored. A cancelled run is not a failure | There is one incident per repository, branch and pipeline. A branch that keeps failing on every push groups into that one incident instead of paging the team again and again, and the first green run on the same branch resolves it. Incident titles stay the same across repeats, which is what makes them readable when Spike reads one out on a phone call: ``` Pipeline failed on main in acme/checkout-api ``` Each incident carries the detail on its page rather than in the title: * Repository, with a link to it in Bitbucket * Branch the run was on * Commit hash, with a link to the commit * Commit author, as reported by Bitbucket * A link straight to the pipeline run, so on-call lands on the failing step * The build status name and description Bitbucket sent {% hint style="info" %} [Alert rules](/alerts/alert-rules) work on this integration like any other. Use them to set severity per repository or branch, route a repository to a different escalation policy, or suppress pipelines you do not want to be paged for. Alerts are suppressed for repeat failures while the incident is open. {% endhint %} ## Prerequisites * A Bitbucket Cloud account with **admin** access on the repository, or on the workspace for a workspace-wide webhook * At least one pipeline defined in `bitbucket-pipelines.yml` * A Bitbucket Pipelines integration in Spike and its webhook URL ## Step 1 — Create the integration in Spike In Spike, go to **Integrations → Add integration → Bitbucket Pipelines**, attach it to a service and an escalation policy, and copy the webhook URL. It looks like `https://hooks.spike.sh//push-events`. {% content-ref url="/pages/-Ln3rb4wLUFeI-OAPcmq" %} [Create integration and service on our dashboard](/integrations-guideline/create-integration-and-service-on-dashboard) {% endcontent-ref %} ## Step 2 — Add the webhook in Bitbucket Pick one of the two below. A repository webhook covers one repository, a workspace webhook covers every repository in the workspace. {% tabs %} {% tab title="One repository" %} Use this when different repositories should page different teams, or when you only want a few repositories in Spike. 1. Open the repository in Bitbucket and go to **Repository settings → Webhooks**. 2. Click **Add webhook**. 3. Fill in the form: * **Title**: `Spike` * **URL**: the webhook URL you copied in Step 1 * **Status**: leave **Active** ticked * **SSL / TLS**: leave certificate validation enabled 4. Under **Triggers**, choose **Choose from a full list of triggers**, and in the **Repository** section tick: * **Build status created** * **Build status updated** 5. Click **Save**. Repeat this for every repository you want in this Spike integration. Repositories that should page a different team get their own Spike integration and their own webhook URL. {% endtab %} {% tab title="Whole workspace" %} Use this when every repository in the workspace should page the same team. One webhook, one Spike integration, no per-repository setup as the workspace grows. 1. From your workspace in Bitbucket, go to **Workspace settings → Webhooks**. 2. Click **Add webhook**. 3. Fill in the form: * **Title**: `Spike` * **URL**: the webhook URL you copied in Step 1 * **Status**: leave **Active** ticked * **SSL / TLS**: leave certificate validation enabled 4. Under **Triggers**, choose **Choose from a full list of triggers**, and in the **Repository** section tick: * **Build status created** * **Build status updated** 5. Click **Save**. Every repository in the workspace now reports to this one integration, and Spike still opens a separate incident per repository and branch. {% endtab %} {% endtabs %} {% hint style="warning" %} Do not point both a workspace webhook and a repository webhook at the same Spike integration for the same repository. Bitbucket would deliver every build status twice. The incidents still group, so you would not be paged twice, but the incident timeline fills with duplicate events. {% endhint %} ## Step 3 — Check it works 1. Push a commit to a branch whose pipeline you expect to fail, or temporarily add a step that exits non-zero. 2. When the run turns red, the incident shows up in Spike with the repository, branch and a link to the run. 3. Fix the branch and push again. The green run resolves that incident. If nothing arrives, open the webhook in Bitbucket and click **View requests** to see the deliveries and the response Spike returned. ## Event payload structure Bitbucket sends the event key in the `X-Event-Key` header and a JSON body. Abridged to the parts Spike reads: ```json { "commit_status": { "name": "Pipeline #142 for main", "description": "Pipeline failed", "state": "FAILED", "url": "https://bitbucket.org/acme/checkout-api/pipelines/results/142", "refname": "main", "type": "build", "created_on": "2026-02-17T09:14:02.120Z", "updated_on": "2026-02-17T09:18:44.881Z", "commit": { "hash": "a1b2c3d4e5f60718293a4b5c6d7e8f9012345678", "links": { "html": { "href": "https://bitbucket.org/acme/checkout-api/commits/a1b2c3d" } } } }, "repository": { "full_name": "acme/checkout-api", "links": { "html": { "href": "https://bitbucket.org/acme/checkout-api" } } }, "actor": { "display_name": "Jane Doe" } } ``` **Key fields:** * `commit_status.state` — `FAILED`, `SUCCESSFUL`, `INPROGRESS` or `STOPPED`. This is what decides whether Spike opens, resolves or drops * `commit_status.name` — the pipeline and run number, used in the incident * `commit_status.url` — link to the pipeline run * `commit_status.refname` — the branch, used for grouping * `commit_status.commit.hash` — the commit that was built * `repository.full_name` — workspace and repository, used for grouping * `actor.display_name` — who pushed the commit that started the run Fields Bitbucket leaves out are simply left off the incident. {% hint style="info" %} Anything that posts a build status to Bitbucket uses this same event, not only Pipelines. If you also run an external CI or a code coverage app that reports build statuses on your commits, their failures reach Spike too. Filter them out with [alert rules](/alerts/alert-rules) if you do not want to be paged for them. {% endhint %} ## Troubleshooting

Nothing arrives in Spike

Open the webhook in Bitbucket and click **View requests**. Bitbucket shows every delivery it attempted along with the response. * No requests at all means the triggers are wrong. Re-open the webhook and confirm **Build status created** and **Build status updated** are both ticked under **Repository**. * Requests with a non-2xx response mean the URL is wrong. It must be the full `https://hooks.spike.sh//push-events` URL from the integration, with nothing trimmed off the end. * Requests that all carry states of `INPROGRESS` mean your runs are not finishing. Spike only acts once a run reports `FAILED` or `SUCCESSFUL`.

Incidents open but never resolve

A `SUCCESSFUL` build status resolves the incident only when it is for the same repository, branch and pipeline. A run on a different branch does not close another branch's incident, which is deliberate: `main` staying red is not fixed by a green feature branch. If someone already resolved the incident by hand in Spike, the later success has nothing to close and is dropped.

Every failing run opens a new incident

Grouping needs the branch, which Bitbucket sends as `commit_status.refname`. Runs started in a way that carries no branch, such as a run against a tag, cannot group with the branch's incidents. Check **View requests** in Bitbucket and look at `refname` on the deliveries that opened the extra incidents.

Incidents from repositories I do not care about

A workspace webhook fires for every repository in the workspace. Either drop it and add repository level webhooks only where you want them, or keep it and suppress the noisy repositories with [alert rules](/alerts/alert-rules).

Someone shared the webhook URL

The webhook URL is the only credential on this integration, so treat it as a secret. If it leaks, archive the integration in Spike and create a new one, then update the URL in Bitbucket.

# Integrate Spike with Blackfire.io Send Blackfire.io alert emails to Spike so alarms open incidents and recovery emails resolve them. Blackfire.io can notify you by email when an alert rule changes state. Spike gives each integration its own email address, so Blackfire's alert emails create incidents in Spike and the recovery email resolves them. {% hint style="info" %} Blackfire's email format is not published. This guide assumes a subject like `[Blackfire] Alarm: {alert rule} on {environment}` and a recovery subject like `[Blackfire] Recovered: …`. Test with a real alert before relying on auto-resolve. {% endhint %} ## Step 1: Create the integration in Spike 1. From the header, click [Add integration](https://app.spike.sh/integrations/new) and select **Blackfire.io**. 2. Give it a name and select the service it should alert. 3. Click **Create integration**. 4. Copy the email address shown on the integration page. It looks like `ced6f1c82327db079e3f@email-hooks.spike.sh`. ## Step 2: Send the alert rule's notifications to Spike 1. Sign in to [Blackfire](https://blackfire.io) and open the **Alerting** dashboard of the environment you want to monitor. 2. Click **Add Alert** to create an alert rule, or edit an existing one, and set its metric, threshold and context. 3. In the notification step, open the channel selection menu and create a new notification channel of type **Email** directly from it, with the Spike address from Step 1 as the recipient. 4. Select that channel for the alert rule and save it. Repeat for every alert rule that should page through Spike. If you would rather keep Blackfire's emails going to your own mailbox, add your address as the Email channel instead and set up a rule in your mail provider that forwards Blackfire's alert emails to the Spike address. Forwarding keeps the subject and body, which is all Spike reads. {% hint style="warning" %} Blackfire may require a specific plan for some notification channels. If the Email channel is missing in your account, check your Blackfire plan. {% endhint %} ## Step 3: Test it Wait for an alert rule to fire, or forward an earlier Blackfire alert email to your Spike address. An incident should appear within a minute. ### Example email Spike receives each email as the fields below. You do not build these yourself; they are shown so you can check what arrives. Firing: ```json { "to": "ced6f1c82327db079e3f@email-hooks.spike.sh", "from": "Blackfire ", "subject": "[Blackfire] Alarm: Checkout p96 response time on Production", "text": "96th percentile response time of Checkout on Production is 1,240 ms, above the 800 ms alarm threshold for 5 minutes.\n\nAlert rule: Checkout p96 response time\nEnvironment: Production\nContext: Web\nMetric: Response time (96th percentile)\nAlarm threshold: 800 ms\nWarning threshold: 500 ms\n\nView alert: https://app.blackfire.io/envs/de33be74-8cb3-48ce-9f08-2e83ccf16500/alerts\n", "html": "

96th percentile response time of Checkout on Production is 1,240 ms, above the 800 ms alarm threshold for 5 minutes.

Alert rule: Checkout p96 response time
Environment: Production
Context: Web
Metric: Response time (96th percentile)
Alarm threshold: 800 ms
Warning threshold: 500 ms

View alert

", "envelope": "{\"to\":[\"ced6f1c82327db079e3f@email-hooks.spike.sh\"],\"from\":\"bounces@blackfire.io\"}" } ``` Recovery: ```json { "to": "ced6f1c82327db079e3f@email-hooks.spike.sh", "from": "Blackfire ", "subject": "[Blackfire] Recovered: Checkout p96 response time on Production", "text": "96th percentile response time of Checkout on Production is back to normal at 310 ms, below the 800 ms alarm threshold.\n\nAlert rule: Checkout p96 response time\nEnvironment: Production\nContext: Web\nMetric: Response time (96th percentile)\nAlarm threshold: 800 ms\nWarning threshold: 500 ms\n\nView alert: https://app.blackfire.io/envs/de33be74-8cb3-48ce-9f08-2e83ccf16500/alerts\n", "html": "

96th percentile response time of Checkout on Production is back to normal at 310 ms, below the 800 ms alarm threshold.

Alert rule: Checkout p96 response time
Environment: Production
Context: Web
Metric: Response time (96th percentile)
Alarm threshold: 800 ms
Warning threshold: 500 ms

View alert

", "envelope": "{\"to\":[\"ced6f1c82327db079e3f@email-hooks.spike.sh\"],\"from\":\"bounces@blackfire.io\"}" } ``` ## How Spike reads the email | Field | Required | Used for | | ----------------- | ----------- | --------------------------------------------------------------------------------------------------- | | `to` / `envelope` | Yes | Identifies your integration from the `{token}@email-hooks.spike.sh` address. | | `subject` | Recommended | Match key for repeats and recovery, and the title fallback. | | `text` or `html` | Recommended | The first sentence about the fault becomes the incident title. `html` is used when `text` is empty. | | `from` | No | Shown in the email preview. | * **Title:** for an alarm or warning, the first content line of the email body, for example *96th percentile response time of Checkout on Production is 1,240 ms, above the 800 ms alarm threshold for 5 minutes.* Greetings, links and `Label: value` lines are skipped, and the title is cut at a word boundary to 200 characters. If there is no such line, the subject is used. A recovery email is titled by its subject, for example *\[Blackfire] Recovered: Checkout p96 response time on Production*. * **Emails with no usable subject:** an email whose subject is empty, or holds nothing but the tag and a state word, has no key. Its title is the fixed *Blackfire alert with no subject* (a recovery: *Blackfire alert recovered*), and all such emails join one open incident. * **Grouping:** Spike derives a key from the subject by removing the leading `[Blackfire]` tag and the state word right after it (*Alarm*, *Warning*, *Alert*, *Triggered*, *Recovered*, *Recovery*, *Resolved* or *Back to normal*). Emails for the same alert rule and environment join the same open incident, including a warning that escalates to an alarm. A state word elsewhere in the subject is part of the rule's name, so the rules *Checkout* and *Checkout alert* stay separate. * **Auto-resolve:** the state word at the start of the subject decides. *Recovered*, *Recovery*, *Resolved* or *Back to normal* marks a recovery email, which resolves the open incident with the same key; *Alarm*, *Warning*, *Alert* or *Triggered* marks an alert. Only when the subject has no state word does Spike read the first sentence, and then only a phrase such as *is back to normal* or *has recovered*. An alert for a rule, endpoint or environment whose name contains *recovery* or *resolved* is therefore still an alert. A recovery email with no usable subject has no key, so it does not auto-resolve: it is added to the open incident with no subject, which you resolve by hand. # Integrate Spike with Blue Triangle Send Blue Triangle alerts to Spike with a Notification Group webhook so a Warning or Critical performance alert pages your on-call team, and the incident resolves itself when the alert clears. [Blue Triangle](https://bluetriangle.com/) monitors web performance for real users and for synthetic tests, and ties it to business impact. An alert fires when a metric you watch, such as Onload Time, crosses a Warning or Critical threshold, and Blue Triangle sends a notification to the people in a Notification Group. Point a Notification Group at a Spike integration URL and a firing alert pages your on-call team, repeats land on the incident already open, and the incident resolves when Blue Triangle reports the alert as `Clear`. {% hint style="warning" %} **Check the payload before you rely on it.** This guide is written from Blue Triangle's alert labels and Active Alerts states. Blue Triangle does not publish a sample webhook body. Send a test notification from your Notification Group to a request inspector first, and compare the keys with the example below. If they differ, contact Spike support with what you captured. {% endhint %} ## What Spike does with each notification Spike reads the `status` field of every delivery. It is compared without regard to case. | `status` | What happens in Spike | | ---------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | | `Warning` | Opens an incident and pages your escalation policy | | `Critical` | Opens an incident and pages your escalation policy | | `Warning` or `Critical` again for an alert that already has an open incident | Added as an event to that incident. It never pages again | | `Clear` | Resolves the open incident for that alert. With no incident open, it is dropped and opens nothing | ## One incident per alert Spike identifies a Blue Triangle incident by `alertName`, the name you gave the alert in Blue Triangle. It is the same on the Warning or Critical notification and on the Clear notification of one alert, which is how a recovery finds its incident: * An alert that keeps notifying while it is firing stays **one** incident and pages once. * A Warning that later becomes Critical joins the same incident. * Two alerts with different names are two incidents. Give every alert a name that is unique and stable. Renaming an alert while it is firing means its Clear notification no longer matches the incident that is open, and a Clear only ever resolves the incident of the alert it names. Read more about [grouping](/incidents/grouping-incidents). If a notification carries no `alertName`, Spike can only match it by its title. That title carries no severity and no readings, so a Warning, the Critical it becomes and the Clear that ends it all find the same incident. ## How incidents are titled | Payload | Incident title in Spike | | ---------------------- | --------------------------------------------------------------------------------------------------------- | | `subject` is filled in | The `subject` text, whitespace collapsed, at most 200 characters | | `subject` is empty | `: — vs threshold () on ` | | No `alertName` | ` alert on `, with no status and no readings | | `status` is `Clear` | `Recovered: on ` (`Recovered: alert on ` without an `alertName`) | | Nothing usable | `Blue Triangle alert with no details` | For example, the body below gives `Checkout page onload time is above 6s in synthetic tests`. With an empty `subject` it gives `Critical: Checkout - Synthetic Onload Time — Onload Time 7.4 vs 6 critical threshold (+23%) on Checkout - Payment, Checkout - Review`. The reading compares `currentValue` with `criticalThreshold` on a Critical notification and with `warningThreshold` on a Warning one. It is left out when `thresholdType` is not `Fixed Value` (a Percent Change or Standard Deviation threshold is not in the metric's units), when either number is missing, when the threshold is 0, or when the change is under 1%. Numbers from 10 up are whole, with thousands separators; smaller ones keep two significant digits. No unit is shown. The place after `on` is the alert's `pages`, up to two, then `+N more`. When there are no pages it reads `in `. If `metric` is empty, `alertType` is used instead. {% hint style="info" %} Write a **Subject Line** on each alert that says what is wrong in plain words. It is the one sentence Blue Triangle sends about the fault, and Spike uses it as the title. Because Spike keys a named alert on `alertName`, a title that changes between notifications, for example with a new reading, still lands on the same incident. {% endhint %} ## Prerequisites * A Blue Triangle account where you can create alerts and Notification Groups * A Blue Triangle integration in Spike and its webhook URL ## Step 1 — Create the integration in Spike In Spike, go to **Integrations → Add integration → Blue Triangle**, attach it to a service and an escalation policy, and copy the webhook URL. It looks like `https://hooks.spike.sh//push-events`. {% content-ref url="/pages/-Ln3rb4wLUFeI-OAPcmq" %} [Create integration and service on our dashboard](/integrations-guideline/create-integration-and-service-on-dashboard) {% endcontent-ref %} ## Step 2 — Point a Notification Group at Spike 1. In Blue Triangle, open **Settings & Administration** (the gear icon) → **Notification Groups**. 2. Create a group, for example `Spike`, or edit the one your alerts already use. 3. Paste the Spike webhook URL from Step 1 into **Custom Webhook Endpoint**. Leave **Custom Webhook Post** empty: text there could arrive as a top-level `message`, which makes Spike skip the Blue Triangle fields. 4. Click **Save & Close**. ## Step 3 — What Blue Triangle sends Blue Triangle builds the notification body itself; there is no template to edit. Blue Triangle does not publish it, so the keys below are modelled on the labels in its alert settings and are not confirmed. A firing notification: ```json { "alertName": "Checkout - Synthetic Onload Time", "subject": "Checkout page onload time is above 6s in synthetic tests", "status": "Critical", "alertType": "Performance", "dataType": "Synthetic", "metric": "Onload Time", "thresholdType": "Fixed Value", "currentValue": 7.4, "warningThreshold": 4, "criticalThreshold": 6, "evaluationWindow": "15 minutes", "trafficSegment": "Checkout", "pages": [ "Checkout - Payment", "Checkout - Review" ], "alertingSince": "2026-10-09T03:12:00Z" } ``` | Field | Required | What it is | | ------------------- | -------- | ------------------------------------------------------------------------------------------------------ | | `alertName` | No | The alert's name. Spike matches repeats and the recovery on it; without it, Spike matches on the title | | `status` | No | `Warning`, `Critical` or `Clear`. Without it a notification opens an incident and never resolves one | | `subject` | No | The alert's Subject Line. Used as the title when filled in | | `metric` | No | The metric the alert watches, such as `Onload Time` | | `alertType` | No | `Performance` or `Performance/Business`. Used when `metric` is empty | | `dataType` | No | `Real User` or `Synthetic` | | `thresholdType` | No | `Fixed Value`, `Percent Change` or `Standard Deviation` | | `currentValue` | No | The Current Measured Level of the metric | | `warningThreshold` | No | The Warning threshold | | `criticalThreshold` | No | The Critical threshold | | `evaluationWindow` | No | How long the alert looks back | | `trafficSegment` | No | The Transaction (Traffic Segment) the alert covers | | `pages` | No | The Page(s) the alert covers: a list of page names | | `alertingSince` | No | When the alert started firing | When the alert recovers, Blue Triangle sends the same alert with `status` set to `Clear`: ```json { "alertName": "Checkout - Synthetic Onload Time", "subject": "Checkout page onload time is above 6s in synthetic tests", "status": "Clear", "alertType": "Performance", "dataType": "Synthetic", "metric": "Onload Time", "thresholdType": "Fixed Value", "currentValue": 3.1, "warningThreshold": 4, "criticalThreshold": 6, "evaluationWindow": "15 minutes", "trafficSegment": "Checkout", "pages": [ "Checkout - Payment", "Checkout - Review" ], "alertingSince": "2026-10-09T03:12:00Z" } ``` ## Step 4 — Use the group on your alerts Assign the `Spike` Notification Group wherever Blue Triangle notifies: on the **Notification** step of an alert, on a Synthetic Monitor, or in Error State Tracking. On each alert, give it a unique **Alert Name** and write a **Subject Line** for the best incident titles. Save. Alerts that Blue Triangle sends as Error State Tracking or Test Failure may carry failure counts instead of thresholds. They still open incidents, with the plain title. {% hint style="success" %} This integration auto resolves. A notification with `status` `Clear` closes the incident for that `alertName`. {% endhint %} ## Troubleshooting * **Incident never resolves**: the `alertName` on the Clear notification differs from the firing one, or Blue Triangle is not sending Clear notifications for that alert. * **A second incident opens when an alert escalates**: compare `alertName` on the two notifications. Different names are different alerts, and different alerts are different incidents. * **Title is a generic sentence from Blue Triangle**: fill in the alert's Subject Line, or leave it empty to get the built title. * **Every incident has the same title, not the alert's**: check that **Custom Webhook Post** is empty on the Notification Group. Text there can replace the Blue Triangle fields. # Integrate Spike with BMC Control-M Integrate Spike with BMC Control-M to receive real-time alerts via Phone calls, SMS, Slack, MS Teams, and more when batch jobs fail or run late. ## Overview [BMC Control-M](https://www.bmc.com/it-solutions/control-m.html) is a workflow orchestration platform for scheduling and monitoring batch jobs across servers and applications. With Spike's Control-M integration, an alert raised by Control-M becomes a Spike incident, and closing the alert in Control-M resolves it. Control-M does not send webhooks itself. It runs an alerts listener script that you provide, and that script posts the alert to Spike. ## How it works * `id` is the Control-M alert id. It stays the same across every `I` and `U` delivery about one alert, so Spike uses it to match them. It may be sent as a string or a number (`0` is an id), and Spike treats `2193`, `"2193"` and `" 2193 "` as the same id. An empty value, a template variable that Control-M did not expand (`$id`, `$ID`, `${id}`, `{{id}}`, `%id%`, `%%ALERT_ID`, ``), or a word for no value (`null`, `None`, `nil`, `undefined`, `NaN`, `n/a`) is not an id. * `eventType` is `I` for a newly issued alert and `U` for an update. Matching is case-insensitive. An `I` delivery opens an incident. A `U` delivery never opens one: it joins the open incident with the same `id`, and is dropped when none is open. Any other or missing `eventType` opens an incident. * `status` is `0` Not\_Noticed (New), `1` Noticed (Reviewed) or `2` Handled (Closed). `0` opens on `I` and joins on `U`. `1` joins and never closes. `2` resolves the open incident with the same `id`, and never opens one, whatever the `eventType`. `status` may be a string or a number; `handled` and `closed` count as `2`, and `noticed` and `reviewed` as `1`, in any case. An unknown `status` never resolves. * Without a valid `id`, Spike falls back to matching by title. Always send `id`: an alert without one cannot be reliably resolved. * Changes to `eventType`, `status`, `severity`, `user`, `updateTime` and `notes` between deliveries do not create a new incident. * The incident title is `{message}: {jobName} on {host}`, for example `Ended not OK: nightly-invoice-export on prod-batch-agent-02`. * `message` is Control-M's own sentence with whitespace collapsed. A variable Control-M did not expand counts as missing. * `: {jobName}` is dropped when `message` already names the job as a whole word, for example `Job nightly-invoice-export failed on prod-batch-agent-02`. * `on {host}` uses `server` when `host` is empty. It is dropped when `message` already names it, or when neither is present. * With an empty `message` the title is `Control-M alert: {jobName} on {host}`, then `Control-M alert on {host}`, then `Control-M alert with no details`. * The title is at most 200 characters. The message is cut at a word boundary with `...` and the `: {jobName} on {host}` part is kept whole, unless that part alone is over 100 characters, in which case the title is cut plainly. * `I`, `U`, Noticed and Handled deliveries of one alert give the same title. `id`, times, `status`, `severity` and `notes` never appear in it. {% hint style="success" %} Auto-resolution is supported for this integration. Spike will also automatically group repeated incidents and suppress alerts while incident is open. {% endhint %} ## Set up instructions **Step 1:** Create a Control-M integration in the Spike dashboard and copy the webhook URL. {% content-ref url="/pages/-Ln3rb4wLUFeI-OAPcmq" %} [Create integration and service on our dashboard](/integrations-guideline/create-integration-and-service-on-dashboard) {% endcontent-ref %} **Step 2:** Configure the alerts listener in Control-M. {% tabs %} {% tab title="Setup on Control-M" %} 1. Enable external alerts for your Control-M environment and choose the alert types to send, as described in BMC's "Sending events to external monitoring tools" tutorial. Set `enableExternalAlerts` to `{"value": "true"}` and `externalAlertTypes` to `{"value": "Alerts"}` with `ctm config systemsettings::set`, so that only job alerts are sent. Control-M system alerts use different status codes and have no `id`, so Spike does not support them: do not send them to this integration. 2. Keep the **default alert template**. Control-M then passes each alert to the **alerts listener script** as arguments that use the field names in the table below (`eventType`, `id`, `status`, `message`, `jobName`, `host` and so on). Do not rename them. 3. Save the listener script below on the machine that runs the alerts listener, and make it executable. Control-M starts it with `/bin/sh`, so it is written in plain POSIX shell. Replace `SPIKE_WEBHOOK_URL` with the URL from Step 1. * BMC documents more than one argument format, depending on the Control-M version and the `useNewAlertFieldsFormat` setting. The script accepts all three: a field name and its value as two arguments (`"id: "` then `"2193 "`), one argument with no spaces (`"id:2193"`), and one argument with spaces around the colon (`"id : 2193"`). * An argument starts a new field only when the text before its first colon is a field name from the table below, or one of the template fields the script drops (`closedByControlM`, `ticketNumber`). Any other text, including a value that contains or ends in a colon such as `Cause: disk full`, is part of the current field's value. * When no argument names a known field, the script posts nothing and exits with status `2`. It also exits non-zero when the post to Spike fails. 4. Register the script with the alerts listener and start it: `ctm run alerts:listener:environment::set `, then `ctm run alerts:listener:script::set `, then `ctm run alerts:listener::start`. 5. Confirm the argument format your listener uses. Set the listener's `listenerLogLevel` to `debug`, raise a test alert and check the Alerts listener log in `$HOME/.ctm/python-logs/`: it records the script's exit status, and `2` means the script found no field it knows. To see the exact arguments, set `ARGS_LOG` at the top of the script to a file path; the script then appends each argument it receives, one per line in brackets. Clear `ARGS_LOG` again once alerts arrive in Spike, because the file holds alert text. ```bash #!/bin/sh # Turns a Control-M alert's arguments into a flat JSON body and posts it to Spike. # Accepts "name: " then "value ", "name:value" and "name : value". SPIKE_WEBHOOK_URL="https://hooks.spike.sh/..." ARGS_LOG="" SENT_FIELDS=" eventType id server fileName runId severity status time user updateTime message runAs subApplication application jobName host type runNo notes " DROPPED_FIELDS=" closedByControlM ticketNumber " if [ -n "$ARGS_LOG" ]; then printf '[%s]\n' "$@" >> "$ARGS_LOG" fi trim() { text="${1#"${1%%[![:space:]]*}"}" printf '%s' "${text%"${text##*[![:space:]]}"}" } is_field_name() { case "$1" in ""|*[!A-Za-z]*) return 1 ;; esac case "$SENT_FIELDS$DROPPED_FIELDS" in *" $1 "*) return 0 ;; esac return 1 } body='{}' name="" value="" add_field() { case "$SENT_FIELDS" in *" $name "*) body=$(printf '%s' "$body" | jq -c --arg k "$name" --arg v "$value" '. + {($k): $v}') ;; esac } for argument in "$@"; do token=$(trim "$argument") case "$token" in *:*) key=$(trim "${token%%:*}") if is_field_name "$key"; then add_field name="$key" value=$(trim "${token#*:}") continue fi ;; esac value="${value:+$value }$token" done add_field if [ "$body" = '{}' ]; then echo "No Control-M field found in the listener's arguments; nothing sent to Spike." >&2 exit 2 fi curl -fsS --max-time 10 -X POST -H 'Content-Type: application/json' -d "$body" "$SPIKE_WEBHOOK_URL" ``` The script needs `jq` and `curl`. A field with no value, such as `user:`, is sent as an empty string. Spaces around each name and value are trimmed. The script produces this body for a newly issued alert: ```json { "eventType": "I", "id": "2193", "server": "IN01", "fileName": "", "runId": "00q2e", "severity": "V", "status": "0", "time": "20261014031207", "user": "", "updateTime": "", "message": "Ended not OK", "runAs": "ctmagent", "subApplication": "invoicing", "application": "finance-batch", "jobName": "nightly-invoice-export", "host": "prod-batch-agent-02", "type": "R", "runNo": "00001", "notes": "" } ``` When an operator handles (closes) the alert, the script sends the same alert with `eventType` `U` and `status` `2`: ```json { "eventType": "U", "id": "2193", "server": "IN01", "fileName": "", "runId": "00q2e", "severity": "V", "status": "2", "time": "20261014031207", "user": "jsmith", "updateTime": "20261014034522", "message": "Ended not OK", "runAs": "ctmagent", "subApplication": "invoicing", "application": "finance-batch", "jobName": "nightly-invoice-export", "host": "prod-batch-agent-02", "type": "R", "runNo": "00001", "notes": "Input file re-delivered, job rerun ended OK" } ``` {% endtab %} {% endtabs %} ### Fields Send these fields and no others. All values are strings. `id`, `eventType`, `status` and `message` drive how alerts open and resolve; `jobName`, `host` and `server` build the title; `severity` sets the severity badge. The rest are kept on the incident. | Field | Control-M name | Meaning | | ---------------- | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | `eventType` | `call_type` | **Required.** `I` = newly issued alert, `U` = update of an existing alert. | | `id` | `alert_id` | **Required.** Unique key of the alert, the same across its `I` and `U` deliveries. | | `status` | `status` | **Required.** `0` Not\_Noticed, `1` Noticed, `2` Handled (Closed). | | `message` | `message` | **Required.** The full text of the alert. It starts the incident title. | | `jobName` | `job_name` | Job that raised the alert. Used in the title. | | `host` | `host_id` | Agent host where the job ran. Used in the title. | | `server` | `data_center` | Control-M/Server. Used in the title when `host` is empty. | | `severity` | `severity` | `V` very urgent, `U` urgent, `R` regular. Sets the incident's severity badge: `V` → sev1, `U` → sev2, `R` → sev3. Never part of the title. | | `type` | `alert_type` | `R` regular, `B` SLA (BIM). Kept only. | | `application` | `application` | The job's application. Kept only. | | `subApplication` | `sub_application` | The job's sub-application. Kept only. | | `fileName` | `memname` | Job file name, often empty. Kept only. | | `runId` | `order_id` | Order id of the job run. Kept only. | | `runNo` | `run_counter` | Run counter of the job execution. Kept only. | | `runAs` | `run_as` | OS user the job runs as. Kept only. | | `time` | `send_time` | When the alert was issued, `yyyymmddhhmmss`. Kept only. | | `updateTime` | `last_time` | When the alert was last modified. Changes on every `U`. Kept only. | | `user` | `last_user` | The user who last changed the alert. Kept only. | | `notes` | `notes` | Note text attached to the alert. Kept only. | On-premises Control-M/EM uses the older names in the "Control-M name" column (`call_type`, `alert_id`, `data_center` and so on). If your listener receives those, map them to the field names in the first column before posting. {% hint style="warning" %} The argument format has not been confirmed on a real Control-M delivery: BMC's sample listener passes `name:` and `value` as separate arguments, while BMC's Alerts page describes `name:value` and a `key : value` format introduced in May 2025. The script accepts all three; check your listener's log as described in Step 2 before relying on it. Auto-resolve depends on Control-M sending a delivery with status `2` when an alert is handled. We expect an operator setting the alert to Handled to do this, but it has not been confirmed on a real delivery; alerts that are never handled stay open in Spike. Control-M has no setting that handles an alert automatically when a rerun ends OK. Alert ids are unique only within one Control-M/EM or SaaS environment. Create one Spike integration for each environment. {% endhint %} ## Test the integration 1. Make a Control-M job end not OK so that it raises an alert, or run the listener script by hand the way Control-M does, for example `/bin/sh listener.sh "eventType: " "I " "id: " "2193 " "status: " "0 " "message: " "Ended not OK " "jobName: " "nightly-invoice-export " "host: " "prod-batch-agent-02 "`. It posts the first body above, limited to the fields you pass. 2. Verify a new incident titled `Ended not OK: nightly-invoice-export on prod-batch-agent-02` is created in Spike. 3. In Control-M, handle (close) the alert, or run the script again with `"eventType: " "U " "status: " "2 "` and the same `id`. 4. Confirm Spike auto-resolves the incident for that `id`. --- [Next Page](https://docs.spike.sh/llms-full.txt/1)