> ## Documentation Index > Fetch the complete documentation index at: https://badixth-dc85e378.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Field Alerts: Threshold, Drop, Imagery, and Weather > Configure the four data-driven alert types - threshold, NDVI drop, new imagery, and weather - that make up the Field Alerts category inside Activity & Alerts. Field Alerts are the data-driven category inside [Activity & Alerts](/guides/activity-and-alerts). They fire automatically when satellite indices, imagery availability, or weather forecasts cross conditions you define, giving you hours or days of lead time over ground observation. Every field alert is produced by a [rule card](/concepts/risk-model) and flows into the same feed as task, map, scout, and system activity. This page covers the four data-driven alert types and their configuration. For the full picture - task activity, scout escalations, delivery matrix, digests, and the unified feed - see [Activity & Alerts](/guides/activity-and-alerts). **Not sure what triggered your alert?** Alerts tell you *something changed*. To decide *what changed and what to do* on a rice field, see [Rice Diagnosis](/guides/Crop/rice-abiotic-stress) - a decision guide covering the three pillars of rice stress: abiotic (drought, salinity, poor soil, submergence), nutrient deficiency (N, P, K, Zn, S, iron toxicity), and biotic (diseases, insect pests, weeds). ## Field Alert Types Triggers when NDVI falls by a defined amount between consecutive imagery acquisitions. Use this to catch rapid deterioration — crop disease, hail damage, or sudden drought stress — as soon as it registers in the data. Triggers when any supported index (NDVI, NDRE, NDWI) crosses a value you set. Useful for monitoring slow-developing stress such as nutrient deficiency or prolonged waterlogging that approaches a critical level over several weeks. Notifies you the moment a new, cloud-free imagery acquisition is validated and available for a field. Use this when you are actively monitoring a disease outbreak or a recently applied treatment and need to know the instant fresh data arrives. Triggers on weather events detected at your field location: frost risk (temperature forecast below 0 °C within 48 hours), drought stress (consecutive days below 30% field capacity), or excessive rainfall (cumulative precipitation exceeding your defined threshold). ## Creating an Alert Navigate to **Fields**, select the field you want to monitor, and click the **Alerts** tab. Existing alerts for this field are listed with their current status. Click **New Alert**. The alert configuration panel opens. Select one of the four alert types: **NDVI Drop**, **Threshold**, **New Imagery**, or **Weather**. The configuration fields update to match the selected type. Configure the trigger conditions for your chosen type: * **NDVI Drop** — set the minimum drop magnitude (e.g., 0.15 between any two consecutive passes) * **Threshold** — select the index and the value it must cross (e.g., NDRE falls below 0.18) * **New Imagery** — no additional conditions; fires on every new validated acquisition * **Weather** — select the event type and set the numeric threshold if applicable Select one or more delivery methods: **Email**, **SMS**, or **Webhook**. You can combine all three for a single alert. See the [Delivery Channels](#delivery-channels) section below for setup details. Click **Save Alert**. The alert activates immediately and begins evaluating conditions against every new imagery acquisition or weather update for this field. ## Delivery Channels Enter up to **five email addresses** per alert. Each address receives a formatted HTML email containing: * Alert name and field * Triggered condition and current index value * A thumbnail of the latest NDVI map with the affected area highlighted * A direct link to the field in the platform Email addresses do not need to belong to platform users — you can notify agronomists, consultants, or farm managers who do not have a login. SMS delivery requires a **verified mobile number** on your account. Go to **Profile > Contact Details** to add and verify a phone number. Each SMS contains a brief summary of the triggered condition and a short link to the field. Standard messaging rates from your carrier may apply. SMS delivery is currently available in Australia, the United States, Canada, the United Kingdom, and the European Union. If you are unsure whether your country is covered, see the [FAQ](/help/faq) or contact support. Enter your endpoint URL. SemaiSens sends a `POST` request to that URL with a JSON payload every time the alert fires. Webhook delivery is ideal for integrating alerts into farm management software, Slack channels, or custom dashboards. Your endpoint must respond with HTTP `200` within 10 seconds. Failed deliveries follow the platform-wide webhook retry policy documented in [API Webhooks](/api/webhooks#retry-policy); on terminal failure the alert transitions to `delivery_failed` and escalates per the Guardrails section below. Review delivery logs under **Settings > Alerts > Webhook Logs**. For full webhook integration documentation, see the [Webhooks API reference](/api/webhooks). ## Webhook Payload Example When an NDVI Drop alert fires, SemaiSens sends a payload structured like this: ```json theme={null} { "event": "alert.triggered", "alert_id": "alr_01j9abc", "field_id": "fld_01j8xyz", "field_name": "North Corn Field", "alert_type": "ndvi_drop", "triggered_at": "2024-07-12T08:34:00Z", "details": { "previous_ndvi": 0.71, "current_ndvi": 0.48, "drop": 0.23 } } ``` The `details` object varies by alert type. Threshold alerts include `index`, `threshold_value`, and `current_value`. Weather alerts include `weather_event`, `forecast_value`, and `forecast_time`. ## Managing Alerts Access all alerts across every field from **Settings > Alerts** in the left sidebar. From this view you can: * **Mute** an alert for a defined period (e.g., during a planned dormancy period or off-season) without deleting it * **Edit** thresholds, delivery channels, or conditions at any time * **Delete** an alert permanently * **View history** — a log of every time an alert has fired, including delivery status for each channel Alert notifications are typically delivered within **30 minutes** of a new imagery acquisition completing validation and ingestion. Weather alerts fire as soon as the underlying forecast data updates, which occurs every six hours. During periods of high imagery volume across the platform, delivery may occasionally extend to 60 minutes. ## Guardrails This module follows the shared [guardrails template](/snippets/guardrails-template). The agent and every non-agent write path must respect these rules. The `alert_rule` is the human-authored configuration; the `alert` is the machine-fired instance. Muting acts on the rule, not the instance. Delivery routing acts on the instance. | Category | Rule | | ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Input validation** | Rule requires: `field_id[]` or `estate_id`, `alert_type` (`ndvi_drop` \| `threshold` \| `new_imagery` \| `weather`), a valid condition matching the type, and at least one delivery channel. NDVI-drop rules require a `drop_pct` between 5 and 50. Threshold rules require an `index`, `operator`, and `value` in range for the index. Weather rules require a `weather_event` from the supported list and a valid `lead_time_hours`. Webhook endpoints must respond HTTP 200 within 10 seconds on creation test. | | **Preconditions** | Every targeted `field_id` must have an active crop cycle. The actor must have write access to every targeted field or estate. At least one delivery channel must be verified for the actor. | | **Refusals** | Creating a rule targeting a field the actor cannot see (entitlements). Muting a rule that produces severity ≥ high signals beyond the bounded window declared by the safety floor. Deleting a rule that has fired within the last 24 hours without a supervisor confirmation. Setting `mute_until` in the past. Creating a rule with a delivery-only-webhook configuration for Critical or High without an on-call fallback. | | **Confirmations** | Delete a rule with an active firing history (irreversible: future firings stop entirely). Mute a rule whose last firing was Critical or High. Bulk edit across estates. Reversible actions (create, edit conditions, edit channels, mute with a near-term expiry, unmute) commit optimistically with a 5-second undo. | | **Soft warnings** | Rule threshold sits inside the noise band for the target index (informational; user can proceed). Rule targets more than 20 fields in one write. Mute window overlaps a period of historically high firings on the target field. New webhook endpoint has never received a delivery. | | **Rate and scope limits** | Bulk rule creation capped at N per org action (org-configurable) because of notification blast radius. Webhook endpoint creation rate-limited per org. No hard cap on total active rules per user; volume is a soft warning, not a refusal. Alert delivery retries follow the platform webhook retry policy; on terminal failure the `alert` transitions to `delivery_failed` and escalates. | | **Audit** | Every rule write conforms to the [Audit Envelope](/snippets/audit-envelope). Module-specific fields: `alert_type`, `conditions_snapshot`, `channels`, `mute_until` (when set), `mute_reason` (when set), `fields_scope[]` or `estate_id`. Every `alert` instance also audits `fired_at`, `matched_rule_id`, `matched_conditions_snapshot`, and per-delivery `channel`, `delivery_outcome`, `receipt_id`. Mutes are audited on the rule (`before_snapshot.mute_until` and `after_snapshot.mute_until`); acknowledgement is audited on the alert instance per user. | | **Escalation** | `delivery_failed` on a Critical or High alert escalates to the estate admin and, if configured, the on-call role. Three failed deliveries on the same rule within 24 hours escalate to the org admin. Attempt to mute a severity ≥ high rule beyond bounds escalates to the estate admin. Rule deletion by a non-admin identity when the rule has fired within 24 hours escalates to the estate admin. | ## Related * [Activity & Alerts](/guides/activity-and-alerts) - the umbrella module. Covers task, scout, map, imagery, and system activity in addition to field alerts, plus the delivery matrix, digests, and AI escalation. * [Risk Model](/concepts/risk-model) - the rule card schema that defines the thresholds behind every field alert. * [Field Scouting](/guides/field-scouting) - turn alerts into GPS-routed scout tasks. * [Notification Preferences](/guides/notification-preferences) - configure channels, quiet hours, and digest cadence.