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:

Open Deployments → Catalog.
Select Jobs and search for security-open-port-alert (or choose the matching security blueprint).
Click Plan & register and configure:
- poll_interval (for example 60s)
- allowed_ports_regex (for example 22|80|443)
- tenant_label
- site_name
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.