starred/healthchecks

Fork 0

mirror of https://github.com/healthchecks/healthchecks.git synced 2026-04-26 07:25:51 +03:00

[GH-ISSUE #393] Spike.sh integration #300

New issue

Closed

opened 2026-02-25 23:41:57 +03:00 by kerem · 7 comments

kerem commented

2026-02-25 23:41:57 +03:00

Owner

Originally created by @noob-master147 on GitHub (Jul 7, 2020).
Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/393

Add integration for Spike.sh

Originally created by @noob-master147 on GitHub (Jul 7, 2020). Original GitHub issue: https://github.com/healthchecks/healthchecks/issues/393 Add integration for Spike.sh

kerem

2026-02-25 23:41:57 +03:00

closed this issue
added the
new integration
label

kerem commented

2026-02-25 23:41:57 +03:00

Author

Owner

@cuu508 commented on GitHub (Jul 9, 2020):

I'm now testing changes from PR #398. In my testing:

when a check goes down, an incident gets created in Spike – all good
when a check goes up, the incident doesn't get resolved, but a new one gets created. Was it intended to work like that?

@cuu508 commented on GitHub (Jul 9, 2020): I'm now testing changes from PR #398. In my testing: * when a check goes down, an incident gets created in Spike – all good * when a check goes up, the incident doesn't get resolved, but a new one gets created. Was it intended to work like that? ![image](https://user-images.githubusercontent.com/661859/87013476-5e258980-c1d3-11ea-9faa-3debc7408e8c.png)

kerem commented

2026-02-25 23:41:57 +03:00

Author

Owner

@cuu508 commented on GitHub (Jul 9, 2020):

In the other incident management system integrations, we pass check's code in JSON payload, so the incident management system can look up the right incident. For example, for PagerDuty, we pass a "incident_key" field. It can then look for open incidents with the same key and update them instead of creating a new one. Perhaps something similar be done here as well?

@cuu508 commented on GitHub (Jul 9, 2020): In the other incident management system integrations, we pass check's code in JSON payload, so the incident management system can look up the right incident. For example, for PagerDuty, we pass a "incident_key" field. It can then look for open incidents with the same key and update them instead of creating a new one. Perhaps something similar be done here as well?

kerem commented

2026-02-25 23:41:57 +03:00

Author

Owner

@cuu508 commented on GitHub (Jul 14, 2020):

Consider a scenario:

I have a check named "Database Backup" that is down
I add a Spike integration in my account
The "Database Backup" check receives a ping and so goes up. A "Database Backup is up" notification gets posted to Spike

In this scenario, I expect Spike to look for an existing open incident, but not find it, and therefore ignore the event. But looks like it creates a new incident instead:

How do you match Healthchecks.io notifications to incidents in Spike? Do you extract check names from the notification text? If yes, that has a couple problems:

check names are not unique and are mutable. User can have multiple checks with identical names. A check can go down, get renamed and then go up
If I change the exact wording in spike_description.html, the integration will likely break

The solution is to use a separate field that is immutable and uniquely identifies the check. The PagerDuty integration calls it incident_key, Opsgenie calls it alias, VictorOps calls it entity_id.

@cuu508 commented on GitHub (Jul 14, 2020): Consider a scenario: * I have a check named "Database Backup" that is down * I add a Spike integration in my account * The "Database Backup" check receives a ping and so goes up. A "Database Backup is up" notification gets posted to Spike In this scenario, I expect Spike to look for an existing open incident, but not find it, and therefore ignore the event. But looks like it creates a new incident instead: ![image](https://user-images.githubusercontent.com/661859/87399152-9d7f1c00-c5bf-11ea-913d-aa227cfc32a2.png) How do you match Healthchecks.io notifications to incidents in Spike? Do you extract check names from the notification text? If yes, that has a couple problems: * check names are not unique and are mutable. User can have multiple checks with identical names. A check can go down, get renamed and then go up * If I change the exact wording in `spike_description.html`, the integration will likely break The solution is to use a separate field that is immutable and uniquely identifies the check. The PagerDuty integration calls it `incident_key`, Opsgenie calls it `alias`, VictorOps calls it `entity_id`.

kerem commented

2026-02-25 23:41:58 +03:00

Author

Owner

@noob-master147 commented on GitHub (Jul 14, 2020):

payload = {
"check_id": str(check.code),
"title": tmpl("spike_title.html", check=check),
"message": tmpl("spike_description.html", check=check),
"status": check.status
}

@cuu508 this is what we plan to send now, this will solve the issue that we are facing.

@noob-master147 commented on GitHub (Jul 14, 2020): payload = { "check_id": str(check.code), "title": tmpl("spike_title.html", check=check), "message": tmpl("spike_description.html", check=check), "status": check.status } @cuu508 this is what we plan to send now, this will solve the issue that we are facing.

kerem commented

2026-02-25 23:41:58 +03:00

Author

Owner

@cuu508 commented on GitHub (Jul 14, 2020):

Added check_id in the payload, but still the same issue. An "up" notification created a new incident:

@cuu508 commented on GitHub (Jul 14, 2020): Added `check_id` in the payload, but still the same issue. An "up" notification created a new incident: ![image](https://user-images.githubusercontent.com/661859/87416239-15a50c00-c5d7-11ea-8478-431b8e32b0fb.png)

kerem commented

2026-02-25 23:41:58 +03:00

Author

Owner

@noob-master147 commented on GitHub (Jul 14, 2020):

yeah @cuu508 i know, we haven't deployed this update on our server yet, I was just informing you.

@noob-master147 commented on GitHub (Jul 14, 2020): yeah @cuu508 i know, we haven't deployed this update on our server yet, I was just informing you.

kerem commented

2026-02-25 23:41:58 +03:00

Author

Owner

@cuu508 commented on GitHub (Jul 15, 2020):

The issue with "up" alerts creating new incidents has been fixed – details in #402

@cuu508 commented on GitHub (Jul 15, 2020): The issue with "up" alerts creating new incidents has been fixed – details in #402

kerem referenced this issue

2026-02-25 23:43:42 +03:00

[GH-ISSUE #1220] Alertmanager integration #823