Outpost

Turn the alerts Outpost sends, such as updated containers or a failed update, into ntfy notifications with the app's name before each title.

Input Handling

The interpreter reads the JSON alert that Outpost 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

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

• Update failed — Outpost also sends it when a whole update check couldn't run.
• 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 Outpost 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 Outpost's 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 [Outpost] Test notification arrives on the context's topic.

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

{
  "id": "outpost-example",
  "name": "Outpost",
  "type": "http",
  "interpreter": "outpost",
  "topic": "containers",
  "mode": "send-once",
  "show_visitor_info": false,
  "primary_server": "primary",
  "servers": ["primary"],
  "token": "replace_with_auth_token"
}

With this context, Outpost posts its alerts to https://outpost-example.ntfy.example.com.

Notification Output

• Title: [Outpost] and the alert's title (e.g., [Outpost] Update failed).
• Body: The alert's message, with HTML tags removed as for every interpreter (see HTML Stripping).
• Priority: The alert's priority, unchanged. Outpost sends 4 for high-priority events and 3 for the rest.
• Tags: outpost first, then the alert's tags (e.g., outpost, whale, warning).

The interpreter sets no icon, actions, or Markdown.

Example

Outpost posts this alert when it rolls back a container that failed its update:

{
  "app": "outpost",
  "details": {
    "containers": [
      {
        "container": "api",
        "image": "ghcr.io/example/api:2",
        "status": "rolled-back",
        "detail": "New container is unhealthy; rolled back to the previous container"
      }
    ],
    "finishedAt": "2026-10-26T04:01:12.480Z"
  },
  "event": "update-failed",
  "message": "Couldn't update 1 container: api (ghcr.io/example/api:2) was rolled back: New container is unhealthy; rolled back to the previous container.",
  "occurredAt": "2026-10-26T04:01:12.503Z",
  "priority": 4,
  "tags": ["whale", "warning"],
  "title": "Update failed",
  "version": 1
}

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

X-Title: [Outpost] Update failed
X-Priority: 4
X-Tags: outpost,whale,warning

Couldn't update 1 container: api (ghcr.io/example/api:2) was rolled back: New container is unhealthy; rolled back to the previous container.

ntfy shows the whale and warning tags as emoji and lists outpost 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 Outpost alerts, but the payload came from transmission-vpn. Set the context's interpreter to transmission-vpn."
}

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.