Routine flaring vs. non-routine flaring: what's the difference

If you work in emissions reporting or ESG diligence long enough, you'll notice operators use "flaring" as if it's one thing. It isn't. The split between routine and non-routine flaring decides which column a given flare lands in on a GHG inventory, which disclosure framework it gets reported under, and whether a regulator treats it as business as usual or as an incident.

Routine flaring is the flaring an operator plans for as part of normal production. Think associated gas at a wellsite with no gathering line, or a facility designed to flare a baseline volume because building out gas capture isn't economic yet. It's continuous, it's expected, and it shows up on a schedule. The World Bank's Zero Routine Flaring by 2030 initiative and the Global Gas Flaring Reduction Partnership (GGFR) both use this category as the thing they're trying to eliminate, because it's the flaring that exists by design rather than by accident.

Non-routine flaring is everything else: well testing, planned maintenance turnarounds, startup and shutdown, a compressor trip, a pipeline outage that leaves gas with nowhere to go but the flare stack. It's episodic. A facility that normally runs a small pilot flame can show a flare three times its usual size for forty-eight hours, then drop back down. Some non-routine events are planned and logged in advance (a scheduled turnaround); some are emergency venting-to-flare that nobody scheduled at all.

How the classification actually gets decided

The classification isn't always obvious from a single night's reading. Most reporting frameworks, including EPA Subpart W and OGMP 2.0, lean on the operator to self-classify, because the reason behind a flare event (was this planned maintenance or an unplanned upset) isn't something a camera alone can tell you. That's the gap regulators and ESG analysts keep running into: the operator knows why the flare happened, but the operator is also the one deciding how it gets reported.

This is where pattern matters more than any single observation. A flare that burns at a steady, low level night after night for a year reads as routine almost by definition, regardless of what the permit paperwork says. A flare that's absent for months and then spikes for a week reads as a non-routine event, even before anyone checks whether it got logged as a turnaround or an upset.

Spotting a non-routine event before the filing does

For anyone tracking a facility or a basin from the outside, the giveaway is the shape of the trend line, not any single flare size. A few patterns worth watching for:

A flare that's never been active before suddenly appears and stays lit for days. That's a strong non-routine signal, usually tied to a startup, a test, or an unplanned shutdown elsewhere in the system that pushed gas to the stack.

An established baseline flare jumps well above its normal size for a short stretch, then returns to baseline. That's consistent with a maintenance event or a temporary capacity constraint, not a change in the underlying production design.

A flare count across a field goes up across multiple sites at once, rather than one facility. That pattern points toward something upstream, a pipeline or processing outage, rather than a single operator's equipment problem.

None of this tells you the operator's internal reason code. It tells you where to ask the question, and it gives you a timestamped record to ask it against, instead of waiting for the next self-reported filing to find out a flare ran hot for three weeks last quarter.

That's the practical use of an independent flare count: it doesn't replace the operator's classification, but it gives you a record of when and where flaring happened that doesn't depend on someone filling out the right form on time. Flare Monitoring builds that record from night-time and SWIR imagery, logging flare counts and sizes across a monitoring area on a nightly cadence, so the trend line exists whether or not the self-report does.

If you're trying to separate baseline flaring from the events operators would rather explain after the fact, a nightly flare log is a reasonable place to start.