Skip to main content
Use the organization-level Webhook integration in Tideways to send performance and error notifications from your PHP applications to Flashduty On-call. Response time and error rate incidents have a full lifecycle: an alert triggers when the incident opens, updates while it continues, and recovers when it closes. Transaction failure rate and missing data notifications are sent once when they occur and never recover. Exception and slow SQL notifications are sent when an error group is new, reopened, or reappears; Tideways sends nothing when the group is resolved, so those alerts do not recover automatically.

In Flashduty On-call

Get the push URL in either of the following ways.

Use a dedicated integration

  1. In the Flashduty console, select Channels and open a channel
  2. Select Settings → Integrations → Dedicated integrations, then click Add integration
  3. Select Tideways and click Save
  4. Open the generated integration card and copy the Push URL

Use a shared integration

  1. In the Flashduty console, go to Integration Center → Alert Events
  2. Select Tideways and enter an integration name
  3. Configure the default route and select a channel. You can add more rules under Routing after creation
  4. Click Save and copy the generated Push URL

Configure Tideways

You need admin permission on the organization. The Tideways webhook only accepts HTTPS URLs and sends no signature or custom headers. Flashduty identifies the integration by the integration_key in the push URL, so keep the URL private.
1

Add a webhook integration to the Tideways organization

Where: Tideways › top-right dropdown menu › Organizations › Integrations › Add New Integration › WebhookSave the integration.
2

Connect the project notifications to the webhook in Tideways

Where: Tideways › top-right dropdown menu inside the project › Project Settings › Configure NotificationsFor each notification rule that needs on-call attention, click Edit, check the webhook integration you just created, and save. If no matching rule exists, create one with Create Notification Rule. The table below shows how Flashduty handles each type.
3

Verify the lifecycle

Where: Tideways › Organizations › IntegrationsPush the application’s response time over the threshold and confirm Flashduty receives an active alert. Tideways opens an incident only after the metric stays above the threshold for the rule’s check period (5 to 60 minutes). After the metric falls back and Tideways closes the incident, confirm the original alert recovers.Preview on the webhook integration’s page sends a response_time notification with status opened and a placeholder incident ID. Flashduty creates a Warning alert from it, and no closed notification follows, so close it manually in Flashduty after verifying.

Alert key

For response time, failure rate, and transaction response time incidents, the Alert Key is computed from the incident ID (notification.incident_id) together with the notification type, organization, and application. The Tideways documentation states that status is opened, ongoing, or closed depending on the incident phase; incidient_id is a misspelled legacy copy of incident_id with the same value, and Flashduty reads it when incident_id is missing. Incident notifications missing both are rejected, and so is an unknown status. Other types use their own object:
  • New exceptions and slow SQL: the error group ID (notification.error_group.id) together with the notification type, organization, and application. A group that appears again merges into the same alert
  • Transaction failure rate and missing data: the notification type, organization, application, environment (environment), service (service), and transaction (transaction). The same check firing again merges into the same alert
Changes to the value, time, threshold, or occurrence count never change the Alert Key. An error group notification with status resolved, not_error, or ignored recovers the alert of that group. The exception rule only notifies for new, reappeared, reopened, and unacknowledged errors, so in practice a resolved group produces no notification; a reopened group merges into its existing alert.

Status and severity

Tideways notifications carry no severity, so Flashduty sets it by type: When status is closed, or an error group is resolved, not_error, or ignored, the alert recovers, and the recovery event keeps the last severity.

When alerts do not recover

Transaction failure rate and missing data notifications are sent once, and Tideways sends no matching recovery, so these alerts do not recover automatically. Exception and slow SQL alerts also stay active after the error group is resolved or ignored in Tideways, because Tideways sends no notification for that. Turn on auto-close for the channel, with the timer starting from Incident triggered and a suggested duration of 24 hours. Missing data and new exceptions are normally handled within a working day. If the channel only receives response time and failure rate notifications, you can leave it off.

Labels

Troubleshooting

  • Tideways shows a delivery failure: confirm the URL uses HTTPS and includes integration_key. Tideways does not retry, and a response with status 400 or higher is only recorded in the integration’s error log
  • Flashduty returns an invalid-parameter error: the message names the missing field (for example notification.incident_id) or the unsupported type
  • An alert did not recover: response time, failure rate, and transaction response time incidents recover on closed, and turn on auto-close for exceptions, slow SQL, transaction failure rate, and missing data. If incident alerts stay active after Tideways closes the incident, check that and when the alert is fixed is ticked on the webhook integration
  • A weekly report or release notification created no alert: these are not incidents, so Flashduty only acknowledges them
For field details, see the Tideways webhook documentation.