Wildfire events in the Timeline Weather API

The Timeline Weather API can return nearby wildfire activity alongside weather data. Wildfire events use satellite fire detections to identify significant thermal activity near a requested location and consolidate those detections into structured fire events.

Wildfire events can help answer questions such as:

  • Is there significant wildfire activity near this location?
  • How far is the nearest detected fire activity from my site?
  • Did wildfire activity occur near a location during a particular period?
  • Which locations in a portfolio have nearby wildfire activity?

Wildfire events are returned through the same events section used for other environmental and severe-weather events.

Beta feature

Wildfire events are currently available as a beta feature. Detection processing, classification thresholds, tuning defaults, event descriptions, and other aspects of the feature may change as the service is refined.

Wildfire events are derived from satellite thermal detections. They are not authoritative wildfire perimeters, emergency alerts, evacuation information, or confirmation that a wildfire is currently burning at a specific property. Detection availability and accuracy depend on satellite overpass timing, cloud cover, fire intensity, viewing conditions, and other observational factors.

Access requirements

Wildfire events are available only on supported Visual Crossing plans and licenses. Some subscriptions do not include access to wildfire event data.

If your account does not include wildfire events, requests using options=includefireevents will return a licensing error.

To request access or evaluate the feature, contact Visual Crossing support or review the current Weather Data Editions and Pricing.

Requesting wildfire events

Wildfire events are not returned by default.

To include them in a Timeline Weather API request:

  1. Include the events section using include=events.
  2. Enable wildfire events using options=includefireevents.

For example:

https://weather.visualcrossing.com/VisualCrossingWebServices/rest/services/timeline/50.52,6.10/2026-08-13/2026-08-18?key=YOUR_API_KEY&include=events&options=includefireevents&contentType=json

Matching wildfire events are returned in each day’s events array alongside any other event types found for the requested location and date range.

Wildfire event response fields

JSON fields

In JSON responses, a wildfire event contains the following fields:

FieldDescription
datetimeLocal time of the satellite overpass with the highest combined Fire Radiative Power (FRP) associated with the event
typefire for wildfire events
latitudeRepresentative latitude of the fire event
longitudeRepresentative longitude of the fire event
distanceDistance from the requested location to the calculated fire-event footprint. A value of 0 means the requested location falls within that footprint
magnitudeHighest combined FRP, in megawatts (MW), observed during a single satellite overpass for the event
descHuman-readable summary of the fire event

A simplified JSON event looks like this:

{
"datetime": "2026-08-15T03:20:00",
"datetimeEpoch": 1786756800,
"type": "fire",
"latitude": 50.51994,
"longitude": 6.10076,
"distance": 0,
"desc": "major | INSIDE fire zone | peak ~3425 MW | total ~26064 MW | 1724 detections, 10.0 mi, Aug 14-Aug 17 (73h) | VIIRS N21/N/N20",
"magnitude": 3425.289999999998
}

The literal INSIDE fire zone description means that the requested location falls within the fire-event footprint calculated from the satellite detections and configured containment buffer. It does not mean that the location is inside an official or authoritative wildfire perimeter.

The distance value is calculated relative to the location used in the Timeline API request, so the same fire event can report a different distance when queried from different locations.

Response distance units follow the requested unitGroup.

Wildfire event searches are limited to a maximum radius of 50 km from the requested location.

CSV fields

CSV output uses different column names for some event properties and includes the standard event columns used by the Timeline API.

The CSV columns are:

name,type,description,dateTime,distance,eventLatitude,eventLongitude,magnitude,size,speed,fscale

For fire events, fields such as size, speed, and fscale are not applicable and are normally empty.

For example:

name,type,description,dateTime,distance,eventLatitude,eventLongitude,magnitude,size,speed,fscale
"50.52,6.10",fire,"major | INSIDE fire zone | peak ~3425 MW | total ~26064 MW | 1724 detections, 10.0 mi, Aug 14-Aug 17 (73h) | VIIRS N21/N/N20",2026-08-15T03:20:00,0,50.52,6.101,3425.29,,,

The corresponding field names differ between JSON and CSV for several event properties:

JSON fieldCSV column
datetimedateTime
typetype
latitudeeventLatitude
longitudeeventLongitude
distancedistance
magnitudemagnitude
descdescription

Understanding the wildfire event description

The JSON desc field (description in CSV) provides a concise summary of the detected fire activity.

Depending on the event, it can include:

  • Event classification such as minor, moderate, or major
  • Whether the requested location falls inside the calculated fire-event footprint
  • Peak observed FRP
  • Total observed FRP summed across detections associated with the event
  • Number of satellite detections
  • Approximate spatial extent
  • Detection date range and duration
  • Satellites contributing detections
  • Indicators that an event may represent an industrial or persistent heat source

For example:

moderate | INSIDE fire zone | peak ~9 MW | total ~78 MW | 41 detections, 0.9 mi, Aug 9-Aug 19 (222h) | VIIRS N/N21/N20

The description is intended primarily as a human-readable summary.

Applications should not depend on the exact wording or position of individual description components remaining unchanged.

Where structured values such as distance, magnitude, latitude, and longitude are available, applications should use those fields rather than parsing the corresponding values from desc.

Wildfire data source

Wildfire detections are based on data from NASA FIRMS, the Fire Information for Resource Management System.

FIRMS distributes active-fire observations from the VIIRS instrument aboard several polar-orbiting satellites, including:

  • S-NPP (Suomi National Polar-orbiting Partnership), reported as VIIRS N
  • NOAA-20, reported as VIIRS N20
  • NOAA-21, reported as VIIRS N21

VIIRS active-fire products provide observations at approximately 375 m spatial resolution.

Each thermal detection includes a Fire Radiative Power (FRP) measurement in megawatts. FRP measures the radiant power observed from the detected heat source at the time of the satellite observation and can be used as an indicator of relative fire intensity.

Satellite observations are individual measurements rather than continuous monitoring. A single wildfire can therefore generate many detections across multiple pixels and multiple satellite overpasses.

The Timeline API groups these observations into fire events so applications can work with consolidated incidents rather than individual satellite pixels.

How satellite detections become fire events

Visual Crossing processes nearby satellite detections to consolidate activity that appears to be associated with the same fire.

Grouping nearby detections

Detections occurring near one another are grouped into a single incident.

The default linking distance is 2.5 km. This prevents a single wildfire from being returned as many independent events because VIIRS detected multiple adjacent hot pixels.

The linking distance can be adjusted using the firelinkkm option.

Calculating the fire-event footprint

A calculated footprint is created from the satellite detections associated with each event.

A small containment buffer is applied around the detections when determining whether the requested location falls within that footprint. The default buffer is 0.75 km and can be changed using firebufferkm.

If the requested location falls within the calculated footprint, distance is returned as 0 and the event description includes:

INSIDE fire zone

Otherwise, distance represents the approximate distance from the requested location to the calculated fire-event footprint.

The fire-event footprint is not a mapped wildfire perimeter.

It is derived from satellite detections and the configured processing buffer. It should not be interpreted as an exact burned-area boundary, fire-line location, or property-level determination.

Fire intensity

The magnitude field contains the highest combined FRP observed during a single satellite overpass for the event.

During a single satellite pass, multiple VIIRS detections can be associated with the same fire event. Their FRP values are combined for that overpass. The peak value is the maximum of these per-overpass combined FRP values.

The datetime field corresponds to the satellite overpass that produced this peak combined FRP.

The description also includes the total observed FRP, calculated by summing the FRP measurements associated with the incident across the available detections.

For example:

peak ~9 MW | total ~78 MW

The peak value therefore represents the strongest combined satellite overpass observation for the event, not the strongest individual detected pixel.

Because the observations occur at discrete satellite overpass times, the summed FRP value should not be interpreted as the total energy released by the fire.

Event classification

Wildfire events are classified as minor, moderate, or major based on peak FRP and the number of associated detections.

The current beta thresholds are:

TierCurrent classification
majorPeak FRP ≥ 200 MW or at least 60 detections
moderatePeak FRP ≥ 25 MW or at least 15 detections
minorBelow the moderate thresholds

By default, the API returns moderate and major incidents and suppresses minor incidents.

The minimum tier can be changed using firemintier.

These classifications and thresholds are part of the beta processing model and may be adjusted as the wildfire-event service is refined.

Applications requiring a specific threshold should explicitly set the appropriate wildfire options rather than relying on the current default behavior.

Filtering industrial and persistent heat sources

Not every thermal source detected by VIIRS is a wildfire.

Gas flares, refineries, industrial facilities, and other persistent combustion sources can produce thermal signatures similar to fire detections. Without additional filtering, these sources could appear repeatedly as wildfire events.

Visual Crossing applies two types of filtering to reduce persistent industrial heat sources in the wildfire results.

Known industrial sources

Candidate events are compared with a catalog of known persistent combustion sites seeded from the Earth Observation Group global VIIRS gas-flare catalog from the Payne Institute for Public Policy at the Colorado School of Mines.

If an incident is associated with a known industrial heat source, it is hidden by default.

The firekeepindustrial option can be used to retain these incidents. Retained incidents are identified in the event description as likely industrial sources.

Persistent heat-source detection

The processing system also examines how thermal detections behave over time.

A heat source that repeatedly occurs within a small geographic area over an extended period can indicate a persistent industrial source rather than a temporary wildfire.

Incidents matching this pattern can be identified as likely persistent or industrial sources.

These filters significantly reduce persistent industrial sources in wildfire results, but they cannot eliminate every false identification. Uncatalogued industrial sources can still be detected, and unusual or long-lived wildfires can sometimes show characteristics similar to persistent sources.

Applications making safety-critical decisions should verify wildfire information using appropriate official and local sources.

Wildfire event options

Wildfire options are passed using the Timeline API options parameter.

Multiple options are separated with commas. Options that accept a value use an underscore between the option name and value.

For example:

options=includefireevents,firemintier_major,firelinkkm_5

The currently supported wildfire options are:

OptionDefaultDescription
includefireeventsoffEnables wildfire events
firemintier_<tier>moderateLowest event tier to return: minor, moderate, or major
firelinkkm_<km>2.5Linking distance used to group nearby detections into a single event. Larger values consolidate detections more aggressively
firebufferkm_<km>0.75Buffer applied when calculating the event footprint and whether the requested location falls within it
firemincount_<n>1Excludes incidents containing fewer than the specified number of detections
fireminfrp_<mw>0Excludes incidents whose cumulative FRP is below the specified value
firekeepindustrialoffRetains incidents identified as known industrial or gas-flare sources rather than filtering them

For example, the following request returns only major events, retains industrial sources, and groups detections using a 5 km linking distance:

https://weather.visualcrossing.com/VisualCrossingWebServices/rest/services/timeline/34.05,-118.24/2026-08-01/2026-08-19?key=YOUR_API_KEY&include=events&options=includefireevents,firemintier_major,firekeepindustrial,firelinkkm_5&contentType=json

Because wildfire events are in beta, defaults and supported tuning behavior may change as the service is refined.

Coverage and data quality

Wildfire detection coverage is global where the underlying satellite observations are available. However, satellite-derived fire information has important limitations that should be considered when using the data.

Satellite observations are not continuous

VIIRS instruments are carried aboard polar-orbiting satellites and observe a location during individual satellite passes.

A fire can start, change significantly, or end between satellite observations. The absence of a recent detection therefore does not necessarily mean that no fire is present.

Cloud cover can obscure fires

Thick cloud can prevent the satellite sensor from observing thermal activity at the surface.

A wildfire may remain active even when no new detections are available during cloudy satellite passes.

Smoke, atmospheric conditions, viewing geometry, and other observational factors can also affect detection.

Small or low-intensity fires may not be detected

Small, short-lived, obscured, or relatively low-intensity fires may not generate a detectable thermal signature during an available satellite pass.

Detection should therefore be interpreted as evidence of observed thermal activity, while the absence of a detection should not be interpreted as proof that no fire exists.

Spatial resolution limits location precision

VIIRS active-fire observations have an approximate spatial resolution of 375 m.

A detection indicates thermal activity within an observed area. It does not mean that the entire detected pixel is burning, nor does it provide an exact fire perimeter.

Calculated event locations, footprints, and distances should therefore be treated as estimates appropriate to satellite-derived fire detection rather than precise property-level boundaries.

Detection count is not the same as fire size

Large or long-lived fires often produce many detections because they extend across multiple pixels and can be observed during multiple satellite passes.

The number of detections associated with an event should not be interpreted directly as its burned area or physical size.

FRP is an observational measure

Fire Radiative Power represents radiant power observed at the time of a satellite detection.

For each satellite overpass, FRP values from detections associated with the event are combined. The highest of these per-overpass totals becomes the event’s magnitude.

FRP is useful for characterizing relative observed fire intensity, but it is influenced by fire behavior, satellite timing, atmospheric conditions, viewing geometry, and other factors.

Peak or cumulative observed FRP should not be interpreted directly as burned area, total energy released, or expected impact at a nearby location.

Non-wildfire heat sources can occur

Although Visual Crossing filters known and likely persistent industrial sources, satellite thermal observations can represent heat sources other than wildfires.

False positives and classification errors therefore remain possible.

Wildfire events should not be used as the sole source for emergency-response, evacuation, property-safety, or other life-safety decisions.

For authoritative wildfire perimeters, warnings, evacuation information, and emergency instructions, consult the appropriate government and local emergency-management sources.

Wildfire Weather Maps API layer

Recent wildfire activity is also available through the Weather Maps API using the fire_history layer.

The layer renders VIIRS detections as an FRP-weighted density visualization, allowing areas with multiple or stronger detections to stand out from isolated low-intensity observations.

The layer currently displays a rolling 24-hour look-back period ending at the requested map time.

A tile request uses the standard Weather Maps API tile endpoint:

https://maps.visualcrossing.com/VisualCrossingWebServices/rest/api/v1/map/tile/fire_history/{z}/{x}/{y}.webp?apikey=YOUR_API_KEY&time=latest

The fire_history layer can be overlaid on a base map or combined with other supported Weather Maps API layers.

For details about tile coordinates, timestamps, output formats, authentication, caching, and map-library integration, see the Weather Maps API documentation.

Access and plan levels

Wildfire events are currently a premium beta feature, and access depends on your Visual Crossing subscription.

If wildfire events are not enabled for your account, a request using includefireevents returns a licensing error rather than silently omitting the requested data.

If you would like to evaluate wildfire events, contact Visual Crossing support to discuss trial access.

For current subscription information, see Weather Data Editions and Pricing.

Questions or need help?

Wildfire events are a beta feature, and we welcome feedback on the data, event classifications, tuning options, and integration experience.

If you have a question, would like to request trial access, or have feedback on the feature, please visit the Visual Crossing support site or post in the Visual Crossing community forum.