Define the Area of Interest and watch points. Write down the districts, watersheds, or communities that matter. Add a short watch list of 10–30 named places: key river towns, bridges, clinics, camps, and known floodplain villages. Put these in a sheet with columns: Name | Type | Coordinates | Notes (why it matters).

Pick two forecast views and one confirmation view. Choose one forecast dashboard that covers the AOI (Flood Hub and GloFAS both can) and one “reality check” source for what is already happening (satellite flood layers and rainfall).

Set simple triggers tied to what the dashboards actually show.

• In Flood Hub, triggers are easiest when tied to the categories and return periods shown for a location. A “1-in-20 year” or worse return period is a strong signal of severe flooding risk, but it is still a probability statement, not a promise.

• In GloFAS, use the “exceedance probability” view if available. A practical trigger is “forecast indicates a high chance of exceeding a high return period” for a watched river reach, plus local vulnerability (settlements on the floodplain).
  Write the triggers as a short SOP in plain language and keep them consistent.

Add rainfall context before sending an alert. Check IMERG rainfall totals upstream for the last 24–72 hours. In practice, look for heavy totals that match the basin size (small basins respond to short, intense rain; large basins respond to multi-day totals). If rainfall is light but the forecast is extreme, treat it as a “watch” and look for model disagreement.

Check soil saturation to avoid “surprise runoff.” Use SMAP to see if soils are already wet. A wet signal means less rainfall is needed to produce flooding. A dry signal means flooding may still happen, but it often requires more sustained rainfall or upstream release. Log “wet / normal / dry” for the AOI in the incident sheet.

Confirm with satellite floodwater layers when possible. In NASA Worldview, add the near-real-time flood layers (search for “Flood NRT” in the layer list), choose the latest day, and compare to what is normally water in that area. Treat this as confirmation of surface water extent, not a perfect boundary. Cloud and terrain shadow can still confuse optical flood mapping, so do not rely on a single frame for a high-stakes call.
If cloud is persistent, use radar-based water extent when available (DSWx-S1 is designed to map surface water regardless of clouds and night).

Send a short alert that separates “forecast risk” from “observed flooding.” Use a consistent template:

• What: Flood Watch or Flood Alert

• Where: place names and river reach

• When: forecast window plus “as of” time for any observed flood layer

• Confidence: forecast-based, confirmed by rainfall and/or satellite, or unconfirmed

• Action: monitor, prepare to move assets, check routes, pre-position staff

Log outcomes and refine triggers weekly. Track false alarms and misses. If alerts are frequent but impacts are minimal, tighten triggers (higher return period, add rainfall threshold, require soils “wet”). If floods are missed, loosen triggers or add a second check time.

Create a single configuration sheet that controls everything. Tabs:

• Watchlist: Name | Type (river, town, facility) | Lat | Lon | Admin area | Notes

• Thresholds: Watchlist Name | Trigger type (CAP, gauge, forecast) | Threshold | Severity mapping

• Recipients: Group name | Channel (email/SMS/WhatsApp) | Contact list

• Templates: Message template text with placeholders (Location, Time, Source, Severity)

Start with two automations that are reliable in most countries.

• CAP polling: Many agencies publish CAP feeds; the automation checks every 10–30 minutes, filters for flood-related alerts, and logs new items.

• Gauge threshold checks: If gauges are available (USGS in the US, or another national service), pull the latest value and compare to thresholds in the sheet.

Normalize every trigger into one “event record.” Write each trigger to a single Event Log tab with columns: Event ID | Timestamp | Source | Location | Severity | Confidence | Link | Action status. This makes deduplication and auditing easy.

Add a lightweight forecast flag without trying to automate everything on day one. Many teams lose time trying to scrape forecast dashboards. A cleaner approach at this stage:

• A human checks Flood Hub or GloFAS once daily.

• If a watch threshold is crossed, they add one row to a “Forecast Flags” tab.

• The automation treats that row like a trigger and sends a prepared message.

Include a satellite confirmation checklist in the outbound message. For any medium or high alert, the message should include one line that tells the recipient how to confirm quickly in Worldview:

• “Worldview: add Flood NRT layer and check latest date for this location”

• “IMERG: check last 24–72h rainfall upstream”

Decide when the system sends automatically vs when it waits for review. A practical rule:

• CAP alerts: send immediately (these are official warnings).

• Gauge exceedance: send immediately if it is a high threshold; otherwise log and wait for a second check.

• Forecast flags: require a human review until the team is confident.

Tune thresholds using the log. Every two weeks, sort the log by “false alarms” and “misses,” then update thresholds. Keep the SOP simple and consistent.

Prepare a QGIS template once. Load admin boundaries, main roads, and a basemap. Set a working CRS appropriate for distance and area in the AOI. Save as “FloodBriefingTemplate.qgz.”

Bring in observed floodwater. For speed, use Worldview to export the Flood NRT GeoTIFF for the event date and AOI, then add it to QGIS. Interpret it as “observed surface water / flood extent signal,” not a depth map. If the AOI is cloudy or the flood is under vegetation, add DSWx-S1 when available because radar can map water through clouds and at night.

Remove permanent water so the map highlights “new water.” Use WorldCover’s water class as a permanent-water mask. Subtract or hide pixels that are normally water, so the briefing focuses on likely flood expansion into floodplains and settlements.

Convert floodwater to a clean briefing footprint. Polygonize the flood raster (or threshold it first if needed), dissolve small fragments, and keep a minimum mapping unit that matches the briefing purpose. Label the footprint clearly as “satellite-derived observed water extent, date/time.”

Calculate exposed population. Use zonal statistics to sum WorldPop population within the flood footprint and within a buffer (for near-term risk). Report both numbers if helpful: “inundated area” and “nearby within 2 km.”

Describe what land types are impacted. Intersect the flood footprint with WorldCover classes to estimate how much flooding overlaps built-up areas and cropland. This makes the map more decision-ready without adding extra layers.

Export a one-slide map plus a short stats box. Keep the layout simple: flood extent, key towns, rivers, admin names, and a text box with the 3–5 most important numbers (people exposed, built-up overlap, major roads affected if known). Export PNG for slides and PDF for print.

Define the unit of action and the “who gets notified” list
Start by choosing the operational unit that decisions will be made on: basin, sub-basin, river reach, or admin unit. Basin-first is usually best for rainfall and soil moisture because it matches how runoff accumulates. Create a small reference table with ID, name, downstream communities/assets, and recipients. This table becomes the backbone for automation and for consistent messaging.

Build a simple event catalog before touching thresholds
Compile past flood dates and affected areas using whatever is available: partner sitreps, national disaster reports, gauge peaks (if present), and quick-look flood maps. Pull the matching satellite context for those events so the catalog includes “what happened” and “what the data looked like.” For each event, store at least: date range, basin/admin IDs, and a confidence rating (confirmed, likely, unclear). This becomes the truth set used to tune triggers and measure false alarms.

Turn IMERG into basin rainfall features that a trigger can use
IMERG is half-hourly precipitation, which is ideal for rolling totals. For each basin, compute rolling 24-hour, 48-hour, and 72-hour accumulations, plus one intensity feature such as the maximum 1-hour rainfall within the last 24 hours. Use Early or Late for near-real-time monitoring, then switch to Final during reviews to tune thresholds against confirmed events. The first version of the trigger can be as simple as “72-hour basin rainfall exceeds a basin-specific threshold,” but the key is that the threshold is not the same everywhere. Mountain basins, urban basins, and flat floodplains often need different trigger levels even inside the same country.
Practical access: use GES DISC subsetting for AOI/time downloads (GeoTIFF/NetCDF) for scripted pulls, and Giovanni for quick visual checks and exports when validating events.

Use SMAP as the wetness modifier and explain it plainly in outputs
SMAP answers “how close is the ground to saturation,” which changes how much rainfall is needed to produce flooding. Convert SMAP to a basin wetness class that non-specialists can interpret. A good starting approach is percentile-based: for each basin, compare today’s SMAP soil moisture to a multi-month or multi-year distribution and label it dry / normal / wet / very wet. Then apply a simple modifier to the rainfall trigger, such as lowering the rainfall threshold when soils are very wet, and raising it when soils are unusually dry. This makes alerts feel more “local” and reduces obvious false alarms.
Practical access: pull an L3 daily SMAP product via NSIDC with Earthdata Login, using the “Customize” option to crop to the area and output format that will load cleanly in GIS.

Design the trigger ladder for action, not just detection
Create two or three alert levels with clear intent:

• Watch: rainfall building and soils supportive of runoff; prompts increased monitoring and partner check-ins.

• Warning: rainfall threshold exceeded with wet soils; prompts readiness actions and targeted community messaging.

• Escalation: rainfall extreme or rapidly intensifying; prompts immediate coordination steps and a request for rapid confirmation layers.
  Keep the logic readable in one paragraph in the SOP, and keep the numeric thresholds in the table. The SOP should also define de-duplication rules so the same basin does not spam recipients every run.

Add SAR confirmation with DSWx-S1, and treat it as “evidence,” not a replacement
When the trigger fires, the workflow should immediately prepare a confirmation task. DSWx-S1 is valuable because SAR can see water through clouds and at night, and the product provides surface water extent at about 30 m with revisit driven by Sentinel-1 acquisitions (often 6–12 days).
How to use it in practice:

• Pull the relevant tiles for the event window from PO.DAAC (or scripted access if running at scale).

• Compare against a baseline water layer to separate “normal water” from “new water.” If a permanent water mask is not available, build a simple baseline from recent DSWx-S1 scenes outside the event window.

• Clip the resulting inundation extent to plausible floodplain areas using HAND (or a local floodplain mask) to reduce radar dark-surface confusion in places like smooth soils, irrigated fields, or calm wet surfaces unrelated to flooding.

• Export a partner-ready GeoPackage and a single-page map showing “triggered basins” and “SAR-confirmed water extent” as separate layers.

Automate the alerting end-to-end, including the message and the audit trail
The “operational pipeline” should do more than compute risk. It should also send a clear message and write a record. A solid minimum automation loop is:

• Scheduled run pulls latest IMERG and SMAP for each basin, recomputes rolling totals and wetness class, and evaluates the trigger ladder.

• If a trigger crosses from not-fired to fired, the system generates: a short table (basin, rainfall totals, wetness class, level), a small map image, and a permanent link to the evidence folder.

• The system sends one alert message per basin per level, with a consistent format: location, level, what changed, what action is expected next, when the next update will occur, and the evidence link.

• The system appends a row to an incident log (timestamp, basin, level, rainfall, wetness, recipients, evidence links).
  This ensures alerts are actually operational, not just analytics.

Optional light ML that stays interpretable
If there is enough historical catalog coverage, train a simple classifier to output a probability of flooding per basin-day using the same features already computed (IMERG rolling totals and intensity, SMAP wetness class, terrain summaries, distance-to-river). Keep it light and transparent: use a small boosted-tree model only if it clearly outperforms the rules and remains calibratable. Select the operating threshold using reliability checks so “0.7 probability” actually behaves like a high-risk bucket in practice.