You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 180a162
Browse filesBrowse the repository at this point in the historyBrowse files
No error output means Flashduty accepted the request. When the application is `Healthy`, this is a recovery message and creates no alert; in an intermediate state such as `Progressing`, Flashduty ignores it.
151
+
The command prints debug logs of the request and response, including the full push URL with its `integration_key`, so do not paste the output anywhere public. A `200 OK` status on the `Received response:` line means Flashduty accepted the request. When the application is `Healthy`, this is a recovery message and creates no alert; in an intermediate state such as `Progressing`, Flashduty ignores it.
Copy file name to clipboardExpand all lines: en/on-call/integration/alert-integration/alert-sources/kentik.mdx
+6-5Lines changed: 6 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -37,8 +37,8 @@ Creating a notification channel requires the Administrator role in Kentik; Membe
37
37
<Steps>
38
38
<Steptitle="Create a Custom Webhook notification channel">
39
39
40
-
1. Log in to the Kentik Portal and go to **Settings** → **Notifications**
41
-
2. Click **Add Notification Channel** and set **Type** to **Custom Webhook**. Do not choose the **JSON** type: Flashduty parses the output of the template below
40
+
1. Log in to the Kentik Portal and go to **Settings** → **Notification Channels**
41
+
2. Click **Add Notification Channel** and set **Type** to **Webhook** (listed as Custom Webhook). Do not choose the **JSON** type: Flashduty parses the output of the template below
42
42
3. Fill in the fields as follows:
43
43
44
44
| Field | Value |
@@ -47,7 +47,7 @@ Creating a notification channel requires the Administrator role in Kentik; Membe
47
47
|**Status**| On |
48
48
|**URL**| The full Flashduty integration push URL, including `integration_key`|
49
49
|**Custom Headers**| Leave empty |
50
-
|**Custom Template**|Paste the template below without renaming any field |
50
+
|**Custom Template**|Click **Go to Notification Template Setup** and paste the template below into **TEMPLATE** on the **Template & Preview** tab, without renaming any field |
51
51
|**Uglify JSON**| Keep the default |
52
52
53
53
```go-template
@@ -75,7 +75,7 @@ Creating a notification channel requires the Administrator role in Kentik; Membe
75
75
}
76
76
```
77
77
78
-
4. Click **Add Notification Channel** to save
78
+
4. Click **Save**
79
79
80
80
</Step>
81
81
@@ -102,6 +102,7 @@ Do not use this channel for mitigation methods or Insights notifications: these
102
102
Flashduty uses the Kentik alert ID (`AlarmID`, shown as **Alert ID** in Kentik) as the Alert Key. Every state-change notification of one Kentik alert, from Active to Cleared, carries the same alert ID, so they merge into one alert, and the clear notification closes it.
103
103
104
104
-**Alerts per key**: an alert policy raises a separate alert for each key (one set of values of the policy dimensions) that matches the conditions. Each alert has its own ID, so each is a separate Flashduty alert that recovers on its own
105
+
-**Synthetics alerts per agent**: a Synthetics test raises a separate alert, with its own ID, for each test agent. A new failure after an alert clears gets a new alert ID and becomes a new Flashduty alert
105
106
- Changes to the description, severity, metric values, or times do not change the Alert Key. Events without `AlarmID` are rejected
106
107
- When one notification carries several events, each event maps to its own alert. A notification with no events is accepted but creates no alert
107
108
@@ -150,6 +151,6 @@ The alert title is the Kentik event description (`Description`), such as `Alarm
150
151
-**`AlarmID is required`**: the channel is used for mitigation or Insights notifications, or the template was changed. Use the channel only for alert policies and Synthetics tests
151
152
-**The alert does not recover**: confirm that the alert is Cleared in Kentik. For policies with **Acknowledgement Required** on, the alert must be acknowledged in Kentik before it can clear (see [Kentik threshold policy settings](https://kb.kentik.com/v1/docs/threshold-policy-settings))
152
153
-**One policy creates several alerts**: the policy alerts on each set of dimension values separately; this is expected
153
-
-**Test notifications**: the content of the Kentik **Test**/ **Test Notification Channels**buttons is defined by Kentik. If it carries an alert ID, Flashduty handles it as a regular alert; close that alert manually in Flashduty
154
+
-**Test notifications**: **Send Test Notification**on the **Template & Preview**tab sends mock data whose event description starts with `[TEST]`; Flashduty accepts it and creates no alert. If you first load a real alert with **Enter Alert ID**, the test carries that alert's real state, and Flashduty handles it as a real notification
154
155
155
156
For field details, see [Kentik notification channels](https://kb.kentik.com/docs/notification-channel) and the [Kentik Custom Webhook templating reference](https://github.com/kentik/custom-notification-templates/blob/main/docs/TEMPLATING_REFERENCE.md).
Copy file name to clipboardExpand all lines: en/on-call/integration/alert-integration/alert-sources/stripe.mdx
+5-4Lines changed: 5 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -43,7 +43,7 @@ You can get the integration push URL in either of the following ways.
43
43
44
44
You need a Stripe role that can manage webhooks, such as Administrator or Developer.
45
45
46
-
1. Sign in to the Stripe Dashboard, open the [Webhooks](https://dashboard.stripe.com/webhooks) tab in Workbench, and click **Create an event destination**
46
+
1. Sign in to the Stripe Dashboard, open the [Webhooks](https://dashboard.stripe.com/webhooks) tab in Workbench, and click **Add destination**
47
47
2. For **Events from**, select **Your account**. If you run a Connect platform and want events from connected accounts, select **Connected accounts** (create one destination for each scope if you need both)
48
48
3. Keep the default **API version**. If you are asked to choose an event payload style, choose **Snapshot**: thin events do not contain the object, so Flashduty cannot parse them
49
49
@@ -71,19 +71,20 @@ If the destination subscribes to other event types (for example `charge.succeede
71
71
72
72
1. Click **Continue** and select **Webhook endpoint** as the destination type
73
73
2. For **Endpoint URL**, enter the full Flashduty push URL
74
-
3.Finish creating the destination. Flashduty does not use the signing secret (starting with `whsec_`) shown on the endpoint page, so you do not need to copy it
74
+
3.Optionally enter a **Destination name**, then click **Create destination**. Flashduty does not use the signing secret (starting with `whsec_`) shown on the endpoint page, so you do not need to copy it
75
75
76
76
Webhook endpoints in test environments (sandbox or test mode) and in live mode are separate. To connect both, create an endpoint in each environment; they can use the same push URL.
77
77
78
78
</Step>
79
79
80
80
<Steptitle="Test">
81
81
82
-
Stripe has no "send test notification" button. Create real test events in a test environment in any of these ways:
82
+
The **Send test events** button on the destination page only shows Stripe CLI instructions and sends nothing. Create real test events in a test environment in any of these ways:
83
83
84
84
- Run `stripe trigger charge.dispute.created` with the [Stripe CLI](https://docs.stripe.com/cli)
85
85
- Pay with test card `4000000000000259`: the payment succeeds and is then disputed as fraudulent. Pay with `4000000000005423` to receive an early fraud warning
86
-
- Submit `winning_evidence` as the dispute evidence: the dispute closes as won and Flashduty recovers the alert
86
+
- Submit `winning_evidence` (or `losing_evidence`) as the dispute evidence: the dispute closes as won (or lost) and Flashduty recovers the alert. Fully refund the early-fraud-warning payment: Stripe sends `radar.early_fraud_warning.updated` with `actionable` set to `false` and Flashduty recovers the alert
87
+
-`payout.failed` needs a failed payout. A sandbox does not accept test bank accounts in its own payout settings; on a Connect platform, pay out from a test connected account whose bank account uses account number `000111111116`, with a destination that receives **Connected accounts** events
87
88
88
89
Test events have `livemode` set to `false`. Flashduty creates alerts for them as usual and adds the label `livemode=false`.
If the command prints no error, Flashduty accepted the request. For an application that has synced before, this notification is the result of its latest sync and merges into that sync's existing record without adding a change; for an application that has never synced, Flashduty ignores it.
128
+
The command prints debug logs of the request and response, including the full push URL with its `integration_key`, so do not paste the output anywhere public. A `200 OK` status on the `Received response:` line means Flashduty accepted the request. For an application that has synced before, this notification is the result of its latest sync and merges into that sync's existing record without adding a change; for an application that has never synced, Flashduty ignores it.
Copy file name to clipboardExpand all lines: en/on-call/integration/change-integration/hcp-terraform.mdx
+8-7Lines changed: 8 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -28,7 +28,7 @@ Notifications are configured per workspace, so configure one for each workspace
28
28
<Steps>
29
29
<Steptitle="Open notification settings">
30
30
31
-
In the workspace, go to **Settings → Notifications** and click **Create a Notification**.
31
+
In the workspace, go to **Settings → Notifications** and click **Create a notification**.
32
32
33
33
</Step>
34
34
@@ -43,11 +43,11 @@ In the workspace, go to **Settings → Notifications** and click **Create a Noti
43
43
44
44
<Steptitle="Select triggers">
45
45
46
-
1. Under **Run Events**, choose to send only specific events and check **Created**, **Planning**, **Needs Attention**, **Applying**, **Completed**, and **Errored**
47
-
2.Leave**Workspace Events** (drift detection, auto destroy, and so on) unselected; Flashduty ignores these notifications
46
+
1. Under **Run Events**, select **All events**
47
+
2.Under**Workspace Events** (drift detection, auto destroy, and so on), select **No events**; Flashduty ignores these notifications
48
48
3. Click **Create a notification**
49
49
50
-
When you save, HCP Terraform sends a verification request. Flashduty accepts it without creating a change. You can verify again later with **Send a Test**.
50
+
When you save, HCP Terraform sends a verification request. Flashduty accepts it without creating a change. You can verify again later with **Send a test**.
51
51
52
52
</Step>
53
53
</Steps>
@@ -70,15 +70,16 @@ You can also manage this configuration with the Terraform `tfe` provider: a `tfe
70
70
| run:planning | planning | Processing |
71
71
| run:needs_attention | for example planned or policy_override (waiting for confirmation) | Planned |
Done, Failed, and Canceled are end states; Flashduty records the change's end time.
78
79
79
80
`planned_and_finished` means a run that only planned (no changes, or a plan-only run). It is also recorded as Done; use the `run_status` label to tell it apart.
80
81
81
-
The following deliveries are accepted without creating a change: the verification request sent on save or by **Send a Test** (trigger `verification`), health assessment notifications (`assessment:drifted`, `assessment:check_failure`, `assessment:failed`), and workspace notifications (`workspace:auto_destroy_reminder`, `workspace:auto_destroy_run_results`, `workspace:deleted`).
82
+
The following deliveries are accepted without creating a change: the verification request sent on save or by **Send a test** (trigger `verification`), health assessment notifications (`assessment:drifted`, `assessment:check_failure`, `assessment:failed`), and workspace notifications (`workspace:auto_destroy_reminder`, `workspace:auto_destroy_run_results`, `workspace:deleted`).
Copy file name to clipboardExpand all lines: en/on-call/integration/change-integration/netlify.mdx
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -53,7 +53,7 @@ In your Netlify project, go to **Project configuration → Notifications → Dep
53
53
| Deploy restored | Recommended, records rollbacks |
54
54
| Deploy request pending, Deploy request accepted, Deploy request rejected | Add these when the project requires approval for untrusted deploys |
55
55
56
-
Deploy locked, Deploy unlocked, and Deploy deleted are not needed: they do not change a deploy's result, and Flashduty accepts them without creating a change. Previously successful deploy failed and Previously failed deploy succeeded repeat Deploy failed and Deploy succeeded, so they are not needed either.
56
+
Deploy locked, Deploy unlocked, and Deploy deleted are not needed: they do not change a deploy's result, and Flashduty accepts them without creating a change.
57
57
58
58
</Step>
59
59
</Steps>
@@ -65,7 +65,7 @@ Deploy locked, Deploy unlocked, and Deploy deleted are not needed: they do not c
65
65
|---|---|---|
66
66
| Deploy | The deploy ID (`id`) | Every notification of one deploy updates the same change; two deploys of the same project and branch are two changes |
67
67
68
-
A rollback (Deploy restored) publishes an existing deploy again, so it updates that deploy's change with status Done and the rollback time as the event time.
68
+
A rollback (Deploy restored) publishes an existing deploy again, so it updates that deploy's change with status Done. The rollback notification carries no rollback time, so the event time is when Flashduty receives it.
69
69
70
70
## Status mapping
71
71
---
@@ -77,7 +77,7 @@ A rollback (Deploy restored) publishes an existing deploy again, so it updates t
77
77
| Deploy started | Processing |
78
78
| Deploy succeeded | Done |
79
79
| Deploy restored | Done |
80
-
| Deploy failed | Failed |
80
+
| Deploy failed | Failed; Canceled when the build was canceled|
81
81
| Deploy request rejected | Canceled |
82
82
83
83
Done, Failed, and Canceled are end states; Flashduty records the change's end time when one arrives.
@@ -117,7 +117,7 @@ Each Netlify notification sends one event. Make sure Deploy started, Deploy succ
117
117
118
118
<Accordiontitle="Does a repeated delivery record a duplicate?">
119
119
120
-
No. A notification with the same deploy, state, and time is recorded once.
120
+
No. When Netlify resends a notification that failed, Flashduty records it at the time of the event itself, and a notification with the same deploy, state, and time is recorded once. Deploy restored is the exception: it is recorded at the time Flashduty receives it, so a resent one is recorded again.
0 commit comments