Notifications and Alerts

LyftData supports general-purpose runtime notifications that can be surfaced in three places:

• Dashboard toast for immediate operator feedback.
• Issues/Problems when the notification is warning/error severity.
• Logs when a job emits the notification with log-event: true.

Use this page for practical setup and troubleshooting.

1. Emit notifications from a job

Use the message action:

actions:
  - message:
      notification-type: alert
      message-content: "Open listening port detected: {{ bind_address }}:{{ port }}"
      log-event: true

Guidance:

• notification-type: alert raises warning-style notifications.
• notification-type: info raises informational notifications.
• log-event: true is required when you want the same signal in Issues and Logs.

2. Deploy the security alert catalog job

The local catalog includes security-open-port-alert (library job + blueprint) for open-port detection.

Typical flow:

1. Open Deployments → Catalog.
2. Select Jobs and search for security-open-port-alert (or choose the matching security blueprint).
3. Click Plan & register and configure:
   • poll_interval (for example 60s)
   • allowed_ports_regex (for example 22|80|443)
   • tenant_label
   • site_name
4. Apply the deployment (or create a job from the library job template).

When a non-allowlisted port is detected, the job emits an alert notification and logs the event for Issues/Logs workflows.

3. MCP notification consumption (pull + push)

Pull (polling fallback)

Use job_notifications_recent when your MCP client cannot open websocket side channels:

{
  "job_names": ["security-open-port-alert"],
  "window_minutes": 30,
  "limit": 200
}

Push (dedicated websocket)

Use mcp_notifications_transport_get to discover runtime endpoints:

• transport.recent_http → /api/mcp/notifications/recent
• transport.subscribe_websocket → /api/mcp/notifications/subscribe

Payload fields:

• message_type (UserNotification or UserAlert)
• severity (info or warning)
• message
• timestamp / timestamp_ns
• optional job_name, worker_id, worker_name

4. Troubleshooting

• Toast appears, but no Issue/Log entry: ensure log-event: true is set on the message action.
• No dashboard toast: verify realtime updates are enabled and websocket traffic to /api/notifications/subscribe is not blocked by proxy/network policy.
• No MCP push events: confirm admin-scoped auth for /api/mcp/notifications/* and verify websocket-capable MCP client behavior; otherwise use job_notifications_recent polling.
• Unexpected alert volume: tighten allowed_ports_regex and/or increase poll_interval.