Alerts

Operational signals from devices, sites, and integrations—scoped, 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.

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 in the database. 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.

Alert visibility#

Workspaces can tune how alerts appear and which events trigger outbound notifications:

ControlWhat it does
Master switchDisable to hide all alerts in the Dashboard and pause destination fanout for the workspace. Capture continues in the background.
Minimum severityShow and notify only for selected levels (CRITICAL, WARNING, INFO).
OEM overridesHide alerts from specific connected integrations (keyed by manufacturer slug) while keeping other sources visible.

Important: Visibility rules take effect only after you save workspace alert settings for the first time. Until then, all alerts remain visible and notifications behave as they did before configuration was introduced.

Configure visibility in the Dashboard under Settings → Alerts.

TopicGuide
Dashboard setup, defaults, and behaviorAlert configuration
REST API — list, create, and lifecycleAlerts API
OEM ingestion paths and provider quirksOEM alert reference

Core data model#

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

FieldDescription
id / externalIdUnique identifiers for the alert in Texture and any upstream system.
workspaceId, siteId, deviceIdScope the alert to a workspace, site, and (optionally) a specific device.
title, descriptionHuman-readable summary and optional detail about the condition.
type, subtypeStructured classification (see Types and subtypes). Prefer these over legacy alertType.
alertTypeLegacy free-text classification. Deprecated in favor of type / subtype.
severityRequired level: CRITICAL, WARNING, or INFO.
statusOperational state: OPEN, ACKNOWLEDGED, IGNORED, or RESOLVED.
sourceSystemWhere the alert originated (Texture automations, OEM adapter, partner integration, manual entry, etc.).
providerName, providerCodeHuman-readable and coded identifiers for the upstream provider when applicable.
acknowledgedAt / by, resolvedAt / by, ignoredAt / by, snoozedUntilResponse workflow and temporary suppression timestamps.
createdAt, updatedAtLifecycle auditing timestamps.
manufacturer, manufacturerDeviceId, deviceName, deviceType, deviceModel, deviceSerialNumberDevice metadata enrichment when available.

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:

ValueMeaning
CRITICALImmediate action required for safety or system availability.
WARNINGElevated attention needed to prevent impact or degraded performance.
INFOInformational events worth monitoring but typically not disruptive.

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 (AlertType)#

TypeTypical domain
COMMUNICATIONSDevice, meter, or controller connectivity
POWER_LIMITSite power limits, ramp rate, power factor
GRID_STATUSGrid forming, following, resync
HARDWARE_FAULTInverter, battery, contactor, generator faults
FIRMWARE_UPDATEFirmware update status
CONFIGURATIONConfiguration or setup issues
VOLTAGE_FREQUENCYVoltage drop, frequency deviation
STATE_OF_ENERGYState of energy, reserve, power saving
TEMPERATUREThermal and overtemperature events
ISLANDINGIslanding / anti-islanding
GENERATORGenerator-related faults
SOFTWARE_PROCESSControl agent or process failures
SENSORSensor faults and disconnects
SYSTEM_SHUTDOWNExternal or GPIO shutdown
PERFORMANCE_DEGRADEDYield or performance below expectation
SITE_LEVELSite-wide conditions
SAFETYSafety-related events
UNKNOWNUnclassified (no mapping rule matched)

Alert subtypes (AlertSubtype)#

SubtypeUsually paired with
BATTERY_METER_COMMSCOMMUNICATIONS
INVERTER_COMMSCOMMUNICATIONS
PV_INVERTER_COMMSCOMMUNICATIONS
SITE_CONTROLLER_COMMSCOMMUNICATIONS
SITE_MAX_LIMITEDPOWER_LIMIT
SITE_MIN_LIMITEDPOWER_LIMIT
RAMP_RATE_LIMITEDPOWER_LIMIT
POWER_FACTOR_LIMITEDPOWER_LIMIT
GRID_FORMINGGRID_STATUS
GRID_FOLLOWINGGRID_STATUS
GRID_RESYNC_FAILEDGRID_STATUS
INVERTER_FAULTHARDWARE_FAULT
BATTERY_FAULTHARDWARE_FAULT
CONTACTOR_FAULTHARDWARE_FAULT
GENERATOR_FAULTHARDWARE_FAULT
OPTICASTER_EXE_FAILEDSOFTWARE_PROCESS
CONTROL_AGENT_CRASHEDSOFTWARE_PROCESS
LOW_SOESTATE_OF_ENERGY
SLEEP_MODESTATE_OF_ENERGY
WAIT_FOR_SOLARSTATE_OF_ENERGY
EXTERNAL_SWITCH_SHUTDOWNSYSTEM_SHUTDOWN
GPIO_SHUTDOWNSYSTEM_SHUTDOWN
EXCESSIVE_VOLTAGE_DROPVOLTAGE_FREQUENCY
FREQUENCY_DEVIATIONVOLTAGE_FREQUENCY
METER_DISCONNECTEDSENSOR
TEMPERATURE_SENSOR_FAULTSENSOR
PERFORMANCE_BELOW_EXPECTATIONPERFORMANCE_DEGRADED

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, device, and pagination. Workspace visibility settings further narrow what appears in the Dashboard after configuration is saved.
  • Destinations — Alert lifecycle events can flow to webhooks, email, SMS, and Kafka. Visibility settings gate fanout; see Alert configuration and Destinations.

Creating and updating alerts#

Texture supports multiple creation paths:

PathDescription
REST APIPOST /v1/alerts publishes alerts from your systems or automations. PATCH endpoints update acknowledgement, ignore, or resolve. See Alerts API.
DashboardOperators can file alerts manually for field-discovered issues. Manual entries use the same schema and lifecycle as API-created alerts.
External ingestionAlerts flow in from OEM platforms and partner applications (for example, SolarEdge, Enphase, Also Energy). Use externalId and provider fields for traceability. See OEM alert reference.

Next steps#

  • Alert configuration — Enable visibility controls and tune severity and OEM filters.
  • Alerts API — List, create, and update alerts via REST.
  • OEM alert reference — Understand provider-specific behavior and volume characteristics.
  • Sites and Devices — See how alerts relate to core platform resources.
  • Destinations — Deliver ALERT_CREATED and related events to external systems.