Monitoring & alerts

Edge devices are, by definition, somewhere you are not. This section is about closing that gap: seeing what a device is doing, keeping the logs you need without drowning in the ones you don’t, and being told when something breaks rather than finding out from a customer.

There are two modes here, and it is worth knowing which one you are in. Looking at a device is what you do when you already suspect something. Alerting is what tells you to go look.

flowchart LR
    DEV["Devices and<br/>applications"] -->|"metrics"| M["monitoring.edgelq.com"]
    DEV -->|"forwarded logs"| L["logging.edgelq.com"]

    M --> LOOK["Device overview<br/><i>you go look</i>"]
    L --> LOOK

    M --> COND["Alerting condition<br/><i>threshold on a metric</i>"]
    COND --> POL["Alerting policy"]
    POL --> CH["Notification channel<br/><i>email, webhook, ...</i>"]
    CH --> YOU(["You are told"])

In this section

• Device overview

  A tour of the dashboard page for a single device: status, hardware details, resource metrics, live and historical logs, reboot, and terminal access.

• Device logs

  What a device forwards and at which severity, how to change it, and how to pull logs on demand instead.

• Alerts

  Alerting policies, conditions, and notification channels: the full path from a metric crossing a threshold to somebody being told.

• Alert metrics

  Which metrics are worth alerting on, and what a sensible threshold looks like for each.

• AI Alerting

  Letting the platform investigate a firing alert, and optionally remediate it, before it reaches you.

• Metrics reference

  The metric types devices report, with their kinds, units, and labels — what you need to query a metric or write an alerting policy as JSON.

• Audit logs

  Who did what, when, and what changed as a result.

What you need

• access to the SPEKTRA Edge dashboard
• a project with at least one provisioned device
• the cuttle CLI, for the parts that use it

If you are missing any of these, Get started sets them up.