Skip to main content
Mezmo’s (formerly LogDNA) Webhook Alert calls a webhook whenever a log view (View) matches the configured number of lines; the request body is rendered from a template you write yourself. This integration syncs matches from one View into one Flashduty alert: repeated matches of the same View and query merge into that same alert.
Mezmo’s own docs say autoresolve “only applies to PagerDuty” — the Webhook channel has no recovery event. So this alert never recovers on its own; it only closes on the channel’s auto-resolve timeout or a manual close. Make sure to complete the “Turn on the auto-resolve timeout” step below.

In Flashduty On-call

You can get the integration push URL in either of the following ways.

Use a dedicated integration

  1. In the Flashduty console, select Channel and open a channel
  2. Select Configuration → Integrations → Private integration, then click Add integration
  3. Select Mezmo, then 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 Mezmo 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 Mezmo

1

Create or open a View in Mezmo

Where: Mezmo › ViewsCreate a View in Mezmo based on a query (for example level:error), or open an existing one. If you plan to reuse the same webhook setup across several Views, you can first create a preset alert template and attach it to each View.
2

Add a Webhook alert on the View

Every field comes from the Body Tokens Mezmo’s own docs list:
Before saving, click Validate JSON below the body editor to confirm the rendered body is still valid JSON.
The field names (view_name, query, …) and their case must match exactly what is shown above — Flashduty parses the request body by these names. Do not rename the Mezmo tokens inside the braces ({{ name }} and so on). Do not add {{ lines }} or {{ line_objects }}: the former is the raw, unescaped text of every matched line and can contain quotes or line breaks that turn the body into invalid JSON once substituted; the latter inserts an array, per Mezmo’s own docs, and cannot be used as a string field’s value.
3

Turn on the auto-resolve timeout in the Flashduty channel

Where: Flashduty console › Channels › Configuration › Settings › AdvancedMezmo’s Webhook Alert has no recovery event and no recovery template to configure — the Update Alert API documents autoresolve as “This property only applies to PagerDuty,” meaning the Webhook channel is not covered. Repeated matches of the same View and query merge into one alert, but that alert never recovers on its own.Once it closes, if the underlying problem is still there, the View fires again on its next observation window and opens a fresh alert.
4

Send a test and confirm a real alert

Click the Test link at the top of the Alert panel and confirm Flashduty returns 200 and opens an alert (Mezmo renders test data through the same template, so Flashduty cannot tell it apart from a real match — close it manually or let the auto-resolve timeout do it). Then let the View’s query actually match some logs and confirm Flashduty opens the corresponding real alert and the integration shows a Latest event time.

Alert key

Mezmo’s Webhook Alert request body has no alert id, View id, or dedup key — none of the 12 documented body tokens (name, matches, lines, level, url, query, app, host, tag, line, line_objects, first_line_object) is an identifier. The View name and the query it runs are the check’s identity across repeated matches — the docs define query as “the query of the View to which this alert is attached” — so Flashduty keys on MD5(view_name, query): repeated matches of the same View and query merge into the same alert (the first matched line, match count, level, and other fields changing does not change this key); a different View, or the same View with an edited query, opens its own alert.

Status and severity

Mezmo’s own docs describe {{ level }} only as “Severity level (info, warn, error, etc)” — the first matched log line’s level — without a full enumeration. Flashduty maps it using the table below; any value not listed, including an empty one (the log line had no parsed level), is treated as Warning:

Labels

The alert title is the View name; the description leads with the raw text of the first matched log line ({{ line }}), followed by the query.

FAQ

No. As long as the View’s name and query stay the same, the Alert Key Flashduty derives from them stays the same too, so repeated matches merge into the same alert (updating the match count, level, and so on rather than opening a new one). That alert still never recovers on its own — once the auto-resolve timeout closes it, if the problem is still there, the next match opens a fresh alert. This is exactly why this integration needs the auto-resolve timeout turned on.
Mezmo’s own docs say autoresolve only applies to the PagerDuty channel; the Webhook channel has no equivalent mechanism and no documented recovery token. Turn on the channel’s auto-resolve timeout, or close the alert manually in Flashduty.
{{ lines }} is the raw text of every matched line, and it can contain line breaks or double quotes; Mezmo’s docs do not say whether it is escaped when substituted into a JSON string. Writing "lines": "{{ lines }}" directly into the template can render invalid JSON the moment a matched log contains a quote or a newline, and Flashduty would then reject that delivery. The template above uses {{ line }} (the first matched line only), which is enough context to act on. If you need the full multi-line content, add it yourself and confirm the escaping with Validate JSON first.
Make sure the push URL is complete, includes integration_key, and is not a private IP — Mezmo rejects webhook URLs pointing to (or redirecting to) 192.168.x.x, 10.x.x.x, or 172.16.x.x–172.31.x.x.
For field details, see Webhook Alert Integration and the Update Alert API.