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 obtain an 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 an 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, select Integration Center → Alert Events
  2. Select Mezmo and enter an integration name
  3. Configure the default route and select a channel; after creation, add more rules under Route if needed
  4. Click Save and copy the generated Push URL

​
Configure Mezmo

1

Create or open a View

Create 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

  1. Open the View’s Alert dialog and select Webhook
  2. Set the number of matching lines and the observation window, for example “10 matches within 30 seconds”
  3. Set Method to POST
  4. Paste the full Flashduty push URL into URL. It must include integration_key
  5. Under Headers, add: Content-Type: application/json
3

Replace the default body

Mezmo pre-fills a default body; clear it and paste the template below. 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.
4

Turn on the auto-resolve timeout

Mezmo’s Webhook Alert has no recovery event — 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. In the channel that receives these alerts, turn on the auto-resolve timeout. We suggest a timeout of 12 hours, counted from Incident trigger. Once it closes, if the underlying problem is still there, the View fires again on its next observation window and opens a fresh alert.
5

Verify

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.

​
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.

​
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.