Define the Area of Interest and what “actionable” means. Write down the exact geography the team cares about (districts, watersheds, corridors, camps, road segments). Then define one or two triggers that will prompt action. Keep them operational, not scientific. Examples: “Any high landslide hazard pixels overlapping a main road corridor we supply” or “High hazard clusters upstream of known debris-flow channels.” LHASA is intended for situational awareness, so triggers should lead to a check, not an automatic public warning.

Check the LHASA nowcast and interpret what it is telling you. Open LHASA and zoom to the Area of Interest. LHASA produces near-real-time global nowcasts at about 1 km resolution and updates daily. It combines satellite rainfall with static susceptibility factors like slope, land cover, and soil to estimate where rainfall-triggered landslides are more likely. Treat it as “conditions are favorable here,” not “a landslide happened here.”

Focus on clusters, not single pixels. In practice, single isolated pixels can be noisy. Look for contiguous clusters of higher hazard. When a cluster overlaps steep terrain and sits above known communities, roads, or rivers, it is more actionable.

Cross-check recent reports in the NASA Landslide Viewer. Open the NASA Landslide Viewer and scan for recent reports in and around the Area of Interest. Use it to answer two questions: “Have there been recent landslides nearby?” and “Are there known recurring locations?” This also helps with trust-building: if LHASA highlights a region and reports are appearing there during a rainy spell, teams learn what “high risk” looks like locally.

Log the daily assessment in a simple, consistent way. Use a table with columns like: Date | AOI | LHASA signal (none, moderate, high) | Location notes | Exposure notes (roads, villages, facilities) | Action taken | Follow-up owner. The goal is repeatability and institutional memory.

Send an internal “watch note” when triggers are met. Keep the message short and consistent: where, why it is flagged, what should be checked, and when the next update will happen. Include a screenshot or a link to the dashboard view if possible.

Start with a saved QGIS template project. Create a project with your admin boundaries, key settlements, critical sites, and a base map. Add empty groups labeled Terrain, Rainfall, Susceptibility, Exposure, Outputs. Save as a reusable template.

Use the DEM to identify steep, landslide-prone terrain. Load the SRTM DEM and generate a slope raster (QGIS Raster Terrain Analysis tools). Slope is not “a landslide map,” but it is a reliable first screen. Style slope into a few classes so steep bands are obvious. The practical interpretation step is visual: identify steep corridors above roads, rivers, and settlements where slope failures can impact access and safety.

Add rainfall and interpret it as a trigger layer. Bring in a rainfall product for the event window. CHIRPS is a common daily rainfall layer for monitoring sustained wet periods; IMERG can provide more frequent estimates for short intense bursts. In QGIS, calculate and map rolling totals such as 1-day and 3-day accumulation for the AOI. Interpretation rule of thumb: short intense totals can trigger rapid failures; multi-day accumulation increases saturation and can lead to broader slope instability. The key is to map where rainfall is concentrated on steep terrain, not just where rainfall is high.

Use soils and land cover as context, not precision truth. Add SoilGrids or HWSD layers and style them lightly. The goal is not to infer geotechnical properties from global datasets, but to provide context such as “areas with different soil types” that may respond differently to prolonged rainfall. Similarly, land cover helps distinguish forested slopes from highly disturbed or built slopes where runoff and instability patterns differ.

Bring in a landslide inventory to sanity-check hotspots. Load the Global Landslide Catalog and any national inventories available. Use them in two ways: confirm known recurring zones, and avoid wasting time on areas that never show historical activity unless exposure is extreme.

Add exposure and produce an “impact-focused” output. Pull roads, buildings, and facilities from OpenStreetMap. Create a simple risk mask by selecting the steep terrain zones and intersecting them with the highest rainfall zones. Buffer that mask upslope of roads and around settlements that sit below steep terrain. Then count and list: road segments intersecting the mask, settlements within the buffer, and any critical facilities. This produces a practical “what may be impacted” view.

Create a new Colab notebook and make the AOI explicit. Start by defining the AOI as a GeoJSON polygon, plus a small configuration block with: AOI name, event window (1-day, 3-day), rainfall trigger thresholds, slope threshold, and alert recipients. Keep configuration separate so non-developers can change thresholds without touching logic.

Pull rainfall time series and compute trigger metrics. Use an accessible source for IMERG and CHIRPS. A practical pattern is to use Google Earth Engine datasets for these products so you can request only the AOI and date range, then export daily summaries. Compute:

• 1-day total rainfall

• 3-day rolling total

• optionally a percentile relative to the last few years of CHIRPS for “unusual wetness”
  Interpretation: the 1-day metric captures intense bursts, the 3-day metric captures saturation. Use both so the system does not fire only on storms or only on slow wet spells.

Apply a terrain screen so triggers focus on plausible slope failure zones. Use SRTM or NASADEM and generate a slope mask for the AOI. In the notebook, compute the percent of the AOI that is both steep and above the rainfall threshold. This prevents alerts that are driven by rainfall over flat floodplains rather than hillslopes.

Turn triggers into a ranked “where to look first” list. Split the AOI into grid cells or admin units, compute rainfall totals per unit, and rank them. Attach simple exposure tags by intersecting the ranked units with OpenStreetMap roads and settlements so the output is actionable.

Automate alert delivery, not just risk scoring. When a trigger is met, generate:

• a short text alert (AOI, date/time window, top 3 locations, why it triggered)

• a small CSV attachment with ranked units and metrics

• optionally a static map image exported from Earth Engine or a lightweight web map link
  Send it automatically by email (SMTP), Slack webhook, or another channel the organization already uses. The alert should include a timestamp and the metric values that caused it, so recipients can trust and audit the system later.

Add SAR confirmation for high-priority triggers. When a trigger is severe or affects critical assets, pull Sentinel-1 scenes before and after the rainfall window. Use ASF search to identify suitable acquisitions. For a fast workflow, submit a HyP3 job to generate a product that helps detect surface change. Then overlay the SAR-derived layer in QGIS with roads and settlements to identify likely failure corridors. SAR can help when clouds block optical imagery.

Optionally tune thresholds with light ML using historical events. Use historical landslide points (Global Landslide Catalog and national inventories) to label days and locations as event or non-event, then fit a simple model that maps rainfall and terrain metrics to a probability score. Keep it interpretable and basin-specific so the team can explain why it fired.