Audience: Local disaster managers, NGO staff, field coordinators, community leaders, and operations teams who can use a web browser and basic spreadsheets.

Prerequisites: Web browser, a simple logging tool (Google Sheet or Excel), and a communication channel (email list, WhatsApp group, SMS tree, radio contact).

Data & Tools:

• Landslide Hazard Assessment for Situational Awareness (LHASA) global landslide nowcast dashboard
• NASA Landslide Viewer (COOLR): a historical database of landslide reports compiled from media and citizen science, useful for establishing historical context during setup. Note: this is not a continuously updated live feed, and is not intended to be checked on a recurring basis.
• Optional: ThinkHazard! for baseline hazard context
• Optional: a simple basemap of the Area of Interest (printed map, Google My Maps, or an existing admin boundary map)
• Optional: a shared incident log (Google Sheet or Excel)

Steps:

1. 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. As a one-time step during setup (not a recurring task), it can help to review the NASA Landslide Viewer for your AOI to understand historical landslide hotspots, since this establishes useful context even though it isn't updated in real time.
2. 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."
3. 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.
4. Log each 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. How often your team checks LHASA and logs an entry is a decision for your organization to make based on its own capacity and the season, not a fixed schedule imposed by this guide.
5. 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.

Outputs: A routine landslide watch process, a log of conditions, and a short internal watch note template.

Validation & QA: On a cadence your team determines, compare watch notes to what actually happened (news reports, partner reports, road closures). Adjust triggers if the team is over-alerting or missing events. Track a simple metric like "How many high-hazard days led to verified impacts in our AOI?"

Maintenance: Update the AOI list and exposure priorities on an ongoing basis, and refresh contacts and escalation paths ahead of each rainy season.

Risks & Considerations:

• False confidence: A "low" nowcast does not mean "safe." Local failures can occur at small scales that 1 km products will not resolve.
• Misinterpretation: Hazard nowcasts are about likelihood, not confirmation. Always label internal notes as "elevated conditions" unless confirmed by field reports.
• Data currency: The NASA Landslide Viewer is a historical database, not a live monitoring feed. Use it to understand past patterns in your AOI, not as a source you check for daily updates.

Audience: Small GIS teams, GIS generalists, and researchers supporting response and preparedness.

Prerequisites: QGIS, basic GIS skills (clip, buffer, raster styling, joins), and ability to download datasets.

Data & Tools:

• An existing landslide susceptibility or hazard product for your AOI, rather than raw inputs to model from scratch: the USGS U.S. Landslide Inventory and Susceptibility Map for US AOIs, or an LHASA nowcast raster export for global AOIs
• OpenStreetMap features (roads, buildings, facilities; download using the HOTOSM exporter tool)
• NASA Global Landslide Catalog and/or USGS Landslide Inventory, used to sanity-check the existing product against known historical events, not to build a new model
• Optional: ThinkHazard! for national-level baseline context
• Optional: land cover (ESA WorldCover or MODIS land cover) for general terrain context

Steps:

1. 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 Hazard/Susceptibility, Exposure, Outputs. Save as a reusable template.
2. Download and load an existing susceptibility or hazard product for your AOI. Rather than building a new model from terrain and rainfall inputs, use the most authoritative existing product available for your geography: the USGS U.S. Landslide Inventory and Susceptibility Map for US AOIs, or an exported LHASA nowcast raster for global AOIs. Style the layer so elevated-hazard zones are visually distinct. Treat this layer as the hazard signal, produced and validated by the originating agency, rather than an in-house calculation.
3. Sanity-check the product against a historical landslide inventory. Load the Global Landslide Catalog and/or USGS Landslide Inventory. Confirm the existing hazard product reasonably aligns with known historical events in your AOI. Where documented events fall outside the flagged hazard zones, note this as a known limitation of the underlying product rather than an error in your own analysis.
4. Add exposure data and produce an "impact-focused" output. Pull roads, buildings, and facilities from OpenStreetMap. Intersect these exposure layers with the elevated-hazard zones from the existing product. Count and list: road segments intersecting the hazard zone, settlements within a buffer, and any critical facilities. This produces a practical "what may be impacted" view without requiring you to have built the underlying hazard model yourself.
5. Optional extension: runout zone delineation with Grfin Tools. For a specific slope already flagged as high hazard by the existing product, Grfin Tools can estimate where material would travel if the slope failed. Run Grfin on the priority location, bring the output polygon back into QGIS, and overlay it with roads/settlements to get a consequence footprint rather than just a hazard likelihood map.

Outputs: A situation map showing an existing agency-produced hazard/susceptibility layer, historical validation points, and exposed assets, plus a short table of priority road segments and communities.

Validation & QA: Confirm projections and units before buffering. Spot-check whether the flagged hazard zones align with real terrain and known events. Review the originating agency's documentation for the product's stated resolution and limitations before relying on it operationally.

Maintenance: Keep the QGIS template and exposure layers up to date on an ongoing basis. Re-check for updated versions of the underlying hazard/susceptibility product periodically, since agencies revise these products over time.

Risks & Considerations:

• Model provenance: You are using someone else's susceptibility model. Understand its stated resolution, inputs, and limitations (via the originating agency's documentation) before relying on it for decisions.
• Resolution mismatch: Global or national hazard products do not capture micro-topography. Use them for screening and prioritization, not parcel-scale decisions.
• Inventory bias: Landslide catalogs often over-represent areas with better reporting. Do not treat "no points" as "no risk."

Audience: Technical GIS and data teams comfortable working across multiple online geospatial platforms; basic scripting is helpful for automating repeated downloads but is not required.

Prerequisites: Web browser and GIS tool (QGIS); optional Python/Colab environment only if your team chooses to automate repeated downloads of existing products.

Data & Tools:

• LHASA nowcast (global, rainfall-driven susceptibility nowcast, produced and maintained by NASA)
• OPERA North America Surface Displacement (DISP) product (InSAR-derived, slow-moving ground deformation, produced by NASA/JPL via ASF DAAC), or an equivalent InSAR-based deformation product from a partner agency for AOIs outside North America
• USGS landslide event-response products (e.g., the USGS Ground Failure product for earthquake-triggered landslides)
• Optional: PAGER, as an early flag that a significant earthquake has occurred and may warrant a check of the USGS Ground Failure product for secondary landslide hazard
• OpenStreetMap, for exposure context

Steps:

1. Identify which existing product matches the trigger you care about. Different hazards are already served by different existing agency products, so start there rather than building something new. Rainfall-triggered, fast-forming landslides: LHASA nowcast. Slow-moving, creeping landslides: OPERA DISP (North America) or an equivalent InSAR deformation product elsewhere. Earthquake-triggered landslides: the USGS Ground Failure product, often flagged first by a PAGER alert.
2. Establish a recurring check of the relevant product(s) for your AOI. Rather than building an automated pipeline, set up a routine, owned by a named team member, for checking the existing product's dashboard or downloading its latest output for your AOI. Document this as a standard operating procedure for your organization, not a claim that the product is being monitored continuously on your behalf by NASA, USGS, or Lifelines.
3. Interpret each product's output using the originating agency's own documentation. Each product has its own resolution, update cadence, and stated limitations (for example, LHASA is roughly 1 km resolution and nowcast-only; OPERA DISP measures line-of-sight displacement and needs multiple acquisitions to build a meaningful time series). Read the agency's guidance before interpreting outputs operationally.
4. Layer exposure data to prioritize where to look first. Bring flagged or elevated-signal areas from the existing product into QGIS and intersect with OpenStreetMap roads, buildings, and settlements to produce a ranked "where to look first" list, using the same exposure-overlay approach as the QGIS workflow above.
5. Confirm high-priority signals with imagery, when available. For a high-priority signal, check whether Sentinel-1 or Sentinel-2 imagery, Copernicus EMS, or the Disasters Charter (if your organization is a registered Authorized User) has recent coverage of the area, to visually confirm ground conditions before escalating.
6. Route confirmed or high-confidence signals into the watch note process from the Daily Landslide Watch workflow above. Keep the alerting and escalation process itself simple and human-owned, consistent with the internal watch note pattern described there, rather than building a fully automated notification system.

Outputs: A documented, human-owned routine for checking existing agency trigger and deformation products, and an exposure-prioritized list of areas to check first when a product flags an elevated signal.

Validation & QA: Track how often flagged signals corresponded to confirmed events, and adjust which product(s) and thresholds your team relies on accordingly.

Maintenance: Periodically confirm that the products you rely on are still active, and check whether the originating agencies have released updated or replacement versions (for example, a DISP-NI product once NISAR data is incorporated).

Risks & Considerations:

• Scope discipline: Building a fully custom automated trigger-and-confirmation system (rainfall thresholds plus SAR-based confirmation) is a substantial undertaking with open technical questions even for well-resourced teams. This workflow intentionally focuses on interpreting existing agency products rather than building new infrastructure.

If your team is interested in trying the more advanced GIS and Remote sensing based workflows, try the ARSET trainings.

• Product-specific limitations: Each existing product (LHASA, OPERA DISP, USGS Ground Failure) has its own stated limitations. Don't treat any single product's output as a confirmed event without a corroborating check.
• Ownership: None of these products constitute a live feed maintained by Lifelines. Any recurring-check routine must be explicitly owned and resourced by the responding organization itself, not assumed to be maintained centrally.