pfSense Actions

Turn the alerts pfSense Actions sends, such as pfSense going unreachable or a failed action, into ntfy notifications with the app's name before each title.

Input Handling

The interpreter reads the JSON alert that pfSense Actions posts to a destination whose service is ntfy-reverse-proxy. Every field below is required, and fields that aren't listed are ignored.

The notification uses title, message, priority, and tags. The event, occurredAt, and details fields must be present, but they don't appear in it.

Supported Events

pfSense Actions sends these alerts, each with a fixed priority and tags:

• Off at first — A new destination leaves Action failed and Wake-on-LAN sent unchecked, so check them in its events to get those alerts.
• Test notification — It's what Send test sends, so a destination can't choose it as an event.

Context Setup

1. Add an HTTP context — Run nrp, choose Manage Contexts > Add, pick HTTP, and choose pfSense Actions as the Interpreter.
2. Deploy — Choose Deploy, then copy the context's URL and token from the Context reference list it prints.
3. Add a destination — On pfSense Actions' Notifications page, select Add notification, choose ntfy-reverse-proxy as the Service, and paste the URL into Context URL. Paste the token into Context token if the context has one, enter a Name, and select Add notification to save it.
4. Send a test — Select Send test on the destination, and check that [pfSense Actions] Test notification arrives on the context's topic.

Under Context URL, the dialog reminds you with Set the context's interpreter to pfsense-actions.

{
  "id": "pfsense-actions-example",
  "name": "pfSense Actions",
  "type": "http",
  "interpreter": "pfsense-actions",
  "topic": "firewall",
  "mode": "send-once",
  "show_visitor_info": false,
  "primary_server": "primary",
  "servers": ["primary"],
  "token": "replace_with_auth_token"
}

With this context, pfSense Actions posts its alerts to https://pfsense-actions-example.ntfy.example.com.

Notification Output

• Title: [pfSense Actions] and the alert's title (e.g., [pfSense Actions] pfSense can't be reached).
• Body: The alert's message, with HTML tags removed as for every interpreter (see HTML Stripping).
• Priority: The alert's priority, unchanged. pfSense Actions sends 4 for high-priority events, 2 for Wake-on-LAN sent, and 3 for the rest.
• Tags: pfsense-actions first, then the alert's tags (e.g., pfsense-actions, warning).

The interpreter sets no icon, actions, or Markdown.

Example

pfSense Actions posts this alert when two scheduled checks in a row can't sign in to pfSense:

{
  "app": "pfsense-actions",
  "details": {
    "address": "192.0.2.1",
    "port": 22
  },
  "event": "pfsense-unreachable",
  "message": "Couldn't sign in to pfSense at 192.0.2.1:22 over SSH in two checks in a row. Actions fail until it answers again.",
  "occurredAt": "2026-10-26T12:10:00.000Z",
  "priority": 4,
  "tags": ["warning"],
  "title": "pfSense can't be reached",
  "version": 1
}

The proxy publishes it to ntfy with these ntfy headers and body:

X-Title: [pfSense Actions] pfSense can't be reached
X-Priority: 4
X-Tags: pfsense-actions,warning

Couldn't sign in to pfSense at 192.0.2.1:22 over SSH in two checks in a row. Actions fail until it answers again.

ntfy shows the warning tag as an emoji and lists pfsense-actions below the notification.

Wrong App Error

A context reads alerts from one app, so a payload whose app names a different app fails instead of arriving under the wrong name. When that app has a built-in interpreter, the proxy answers with HTTP 422 and names the interpreter to use:

{
  "status": "error",
  "message": "This context reads pfSense Actions alerts, but the payload came from outpost. Set the context's interpreter to outpost."
}

If app contains an unknown producer key, the error instead says the app is unsupported and lists the supported interpreter keys. It never recommends configuring the unknown value.

• Fix — Set the context's interpreter to the key the message names, or point that app at a context that uses its own interpreter.
• Send test — The sending app reports that the test couldn't be sent, with HTTP 422 and up to 120 characters of this message as the reason.
• Error topic — If the context has an error_topic and error_events includes interpretation (or is omitted), the proxy also sends an Interpretation Error with error-debug.json to that topic.
• Other payloads — A non-empty body that isn't JSON, or JSON that isn't an alert (such as one without title, or with a version other than 1), also fails with HTTP 422 before the app is checked.