How alerts work

Operational signals from devices, sites, and integrations — captured, classified, and actionable

Alerts surface operational issues, notifications, and insights across the Texture platform. They consolidate signals from devices, sites, external services, and Texture automations so operators know what needs attention. Each alert records what happened, where it occurred, how severe it is, and what actions have been taken.

This page is the reference for alerts: the capture principle and data model, how alerts are classified, and how alerts arrive from OEM integrations. To act on a single alert, see Read an alert.

Why alerts matter#

• Situational awareness — Maintain a real-time pulse on device health, site performance, and platform automations.
• Coordinated response — Track acknowledgement, remediation, and resolution so teams never duplicate effort.
• Platform-wide connectivity — Link alerts to Sites and Devices for fast navigation between an incident, the underlying asset, and related context.
• Auditable history — Preserve a full record of status changes, snoozes, and resolutions for compliance and post-event analysis.

Capture principle#

Texture always captures incoming alerts, regardless of workspace visibility settings. When you hide alerts or narrow severity and OEM filters, the platform still stores every alert. Filtering applies only to what operators see in the Dashboard and what external systems receive through Destinations (for example, ALERT_CREATED webhooks). Nothing is deleted or dropped at ingestion.

This separation keeps a complete audit trail while letting each workspace control noise in the UI and notification pipeline.

Core data model#

Alerts follow a consistent schema across the API and Dashboard. Key fields include:

Alerts are linked to their workspace, site, and device, so you can navigate from an incident to the underlying assets in the Dashboard and API responses.

Classification#

Severity#

Severity communicates how urgently an alert must be handled:

Status lifecycle#

Operators drive an alert through these states:

1. Open (OPEN) — Newly created and awaiting action.
2. Acknowledged (ACKNOWLEDGED) — Someone is actively working the issue.
3. Ignored (IGNORED) — Intentionally suppressed without resolution (for example, a false positive).
4. Resolved (RESOLVED) — Root cause addressed and the alert closed.

Snoozing sets snoozedUntil to pause follow-up for a defined window without changing the underlying status.

Types and subtypes#

Use type and (optionally) subtype to classify alerts for filtering, routing, and analytics. Ingestion pipelines map free-text OEM messages into these canonical values where possible.

Alert types#

Alert subtypes#

Creating and updating alerts#

Texture supports multiple creation paths, all sharing the same schema and lifecycle:

Alert settings#

Each workspace can hide alerts by severity or by integration without losing data. See Alert settings.

OEM alert ingestion#

Alerts ingested from OEM and partner systems share the same Texture schema, but each integration differs in polling cadence, severity mapping, resolution behavior, and volume. Use this section when tuning configuration or investigating noisy fleets.

Provider key vs. connection slug#

Two identifiers appear in the Dashboard and documentation:

When the keys differ, overrides may not apply. Usually the connection slug and stored Alert.provider match (for example, enphase / enphase). When they differ (notably SolarEdge: slug solaredge-web, provider solaredge), an OEM override toggled in the Dashboard may not hide alerts until the override key matches the stored provider value. Filtering compares overrides against Alert.provider, not the display fields.

Provider summary#

Manual and programmatically created alerts use other provider values (for example manual, or values you supply when creating an alert).

Provider severity & status mapping#

• SolarEdge — severity derived from numeric impact (high → CRITICAL, moderate → WARNING, zero/low → INFO); status prefers serverStatus, else infers from open / muted flags. Quirks: high INFO volume, cross-poll deduplication, rich HTML descriptions, some types auto-clear after sustained normal operation, and the OAuth v2 endpoint lacks date-range / pagination.
• Enphase — codes 1–2 → CRITICAL, 3 → WARNING, 4–6 → INFO; status is OPEN until alarm_end_time is set, then RESOLVED. Severity may arrive as number or string (normalized); unknown codes may fall back to INFO.
• SMA — Error / Disturbance → CRITICAL, Warning → WARNING, Info → INFO; Appeared (or missing) → OPEN, Solved → RESOLVED. Quirks: duplicate status pings (deduplicated, but bursts after reconnects) and rapid Appeared / Solved cycles.
• Also Energy — severity / status derived from alert code, title, and hardware state; codes mapped to type / subtype where known. Hardware-centric; grant-scoped polling; can be feature-gated per manufacturer during maintenance.
• ChargePoint / Generac / Tesla — publish via the OEM adapter with stable provider keys matching their slug in most cases (Tesla grid-services connection slug may differ from provider).

Working with alerts across the platform#

• Sites and devices — Each alert references its originating site and, when applicable, a device. Site and device views expose associated alerts for impact and history.
• Search and filtering — Filter by type, subtype, severity, status, site, and device. Workspace visibility settings further narrow the Dashboard after configuration is saved.
• Destinations — Alert lifecycle events can flow to webhooks, email, SMS, and Kafka. Visibility settings gate fanout.

Next steps#

• Tune severity and OEM filters in Alert settings.
• Connect Sites and Devices to see how alerts relate to core platform resources.
• Set up Destinations to deliver ALERT_CREATED and related events to external systems.