NERC GADS Forced Outage Reporting Rules: Classification, Timing, and Submission

NERC Generating Availability Data System (GADS) forced outage reporting depends on two determinations made at the moment a problem is detected: which event type applies, and when the event started. If either determination is wrong, the unit’s forced outage hours, and every availability statistic built on them, are wrong for the reporting period. Where a market’s accreditation methodology consumes those statistics, as PJM and NYISO do with EFORd, the error also changes the unit’s accredited capacity value.

NERC GADS forced outage reporting rules in brief

NERC GADS forced outage reporting rules require Generator Owners on the NERC Compliance Registry to classify and time-stamp every forced event on a reportable unit, then submit it under Section 1600 of the NERC Rules of Procedure. This article works from the 2026 GADS Data Reporting Instructions for conventional units, effective January 1, 2026, with the 2026 Wind DRI and 2025 Solar DRI where renewable scope differs.

• Who reports: Conventional units of 20 MW nameplate and larger, wind plants of 75 MW Total Installed Capacity and larger, and solar plants of 20 MW Plant Total Installed Capacity and larger, each under its own DRI.
• What is forced: Conventional GADS treats U1 (immediate), U2 (delayed, within six hours), and U3 (postponed, before the end of the next weekend) as Unplanned (Forced) Outages, and SF (startup failure) as a forced event that also accumulates to forced outage hours.
• When to submit: Event and performance data go to NERC quarterly, within 45 days after each calendar quarter ends.
• Why classification matters: U1, U2, U3, SF, and forced deratings D1–D3 enter forced outage hours and equivalent forced derated hours; MO, PO, and D4 do not.

The rest of this article explains each of those rules with the DRI’s own wording, then shows how classification changes the calculated result. Readers new to the program can start with an overview of what NERC GADS is.

Who has to report to NERC GADS

GADS scope is set per resource type, each with its own threshold, capacity basis, and DRI. The obligation comes from a Section 1600 data request that the NERC Board of Trustees approved on November 16, 2022, effective January 1, 2024, under Section 39.2(d).

Conventional units

NERC has required reporting since January 1, 2013, for conventional units with a nameplate capacity of 20 MW and larger, under the 2026 GADS DRI.

• Capacity basis: Nameplate, measured at the unit level. Multiple boilers or turbine-generators headed together report as one Miscellaneous Unit.
• Start of reporting: The first full month following the Commercial Operating Date. No COD cutoff applies.
• Prerequisite: Nine mandatory design data fields must be on file before any event or performance record is accepted.
• Voluntary participation: Units below 20 MW and non-registered companies can report voluntarily.

Wind plants

The 2026 GADS Wind DRI, Version 4.9, requires reporting from Generator Owners operating wind plants with a Total Installed Capacity of 75 MW or greater and a commercial date of January 1, 2005, or later for any portion of the plant.

• Capacity basis: Total Installed Capacity equals the combined Subgroup Installed Capacity, excluding Energy Storage Capacity. It is the number of turbines times Turbine System MW, and it differs from Plant Capacity at the Point of Interconnection.
• Aggregation: Plant level, not individual turbines.
• Timing: Configuration data is due in the first full month after COD; monthly performance data begins with the third full month after COD. A reportable event after COD must be reported even if performance reporting has not started.

Solar plants

The 2025 GADS Solar DRI, Version 1.7, effective January 1, 2025, requires reporting from Generator Owners of solar plants with a Plant Total Installed Capacity of 20 MW or greater and commercial operation beginning January 1, 2010, or later, regardless of interconnection.

• Capacity basis: Combined Inverter Group Installed Capacity, excluding Energy Storage Capacity.
• Phase-in: Plants of 100 MW and above were mandatory in 2024; 20 MW and above from 2025 onward.
• Timing: Same as wind. Configuration in the first full month after COD, performance from the third full month, and post-COD events reported regardless.

Energy storage

Standalone battery storage has no GADS reporting obligation today: “Standalone Energy Storage is not required at this time. Only Energy Storage connected to a Wind or Solar plant is required,” in the wording of NERC’s 2025 training. NERC’s 2026 State of Reliability overview adds that standalone storage data “is not currently collected by NERC under a Section 1600 data request” and is under evaluation by NERC’s Performance Analysis team.

Storage connected to a reportable wind or solar plant is a different case. Its MW does not count toward the 75 MW or 20 MW threshold, but once the plant is reportable, the storage reports through dedicated Energy Storage Group configuration and monthly performance records, including charge and discharge generation and hours and forced, maintenance, and planned outage hours, according to NERC’s storage performance training. A storage-only loss does not trigger a plant-level event, because the plant event trigger is a forced loss of at least 20 MW of Plant Total Installed Capacity, which excludes storage.

Category 2 registration, effective May 15, 2026, brings owners of non-BES inverter-based resources of 20 MVA aggregate nameplate or more connected at 60 kV or above onto the registry, including BESS, according to NERC’s CMEP practice guide. Those newly registered owners report to GADS only when a plant meets the existing Section 1600 criteria above, according to NERC’s who-and-when training. Registration expands the reportable population; it does not create a standalone BESS dataset.

What counts as a forced outage under conventional GADS

Conventional GADS defines a forced outage by urgency of removal rather than cause. U1, U2, and U3 are the three Unplanned (Forced) Outage types in the 2026 DRI, and the 2026 DRI also classifies Startup Failure (SF) as a forced event, which occurs when a unit cannot synchronize.

The taxonomy comes from IEEE Standard 762. The 2024 DRI states that “The definitions promulgated by the Institute of Electrical and Electronic Engineers’ (IEEE) Standard 762, ‘Definitions for Reporting Electric Generating Unit Reliability, Availability and Productivity’ were incorporated.” IEEE approved the active edition, IEEE 762-2023, on March 30, 2023. It supersedes the 2006 edition and adds considerations for variable energy resources.

NYISO’s forced outage reference documents five IEEE 762 unplanned outage classes: Class 0 (starting failure), Class 1 (immediate), Class 2 (delayed, within 6 hours), Class 3 (postponed, before the end of the next weekend), and Class 4 (deferred beyond the next weekend but before the next planned outage). GADS maps SF, U1, U2, and U3 to Classes 0 through 3. Class 4 corresponds to what GADS reports as a Maintenance Outage.

GADS departs from IEEE 762 in specific places, and reporting teams must apply those departures when classifying real events:

• U1 applies to units that are not in service. GADS U1 covers removal “from service, another outage state, or a reserve shutdown state,” where IEEE Class 1 says only “immediate removal from the existing state.”
• U2 and U3 are in-service only. GADS adds “This type of outage can only occur while the unit is in service” to both; IEEE 762 does not restrict eligibility that way.
• Industry interpretation is acknowledged. The 2024 DRI states that “the experiences of the industry also dictate interpretations of which outage type is most appropriate for a situation.”

Reserve Shutdown falls outside these forced-outage classifications. The 2026 DRI defines RS as “an event where a unit is available for load but is not synchronized due to lack of demand,” and requires that any equipment-related shutdown be reported as an Unplanned (Forced), Maintenance, or Planned Outage rather than RS.

U1, U2, U3, and SF: the timing tests that separate them

The six-hour mark and Sunday at 2400 are the two boundaries that separate the three forced outage types, and both are measured from the moment the problem is detected while the unit is running. The definitions below use the 2026 DRI’s wording.

• U1, Unplanned (Forced) Outage, Immediate: “This is an outage that requires immediate removal of a unit from service, another outage state, or a reserve shutdown state.” No hour window applies, and U1 is the only forced type that can start from an outage or RS state.
• U2, Unplanned (Forced) Outage, Delayed: “This is an outage that does not require immediate removal of a unit from the in-service state, instead requiring removal within six hours. This type of outage can only occur while the unit is in service.”
• U3, Unplanned (Forced) Outage, Postponed: “This is an outage that can be postponed beyond six hours but requires that a unit be removed from the in service state before the end of the next weekend (Sunday at 2400 or before Sunday turns into Monday). This type of outage can only occur while the unit is in service.”
• SF, Startup Failure: “This is an outage that results when a unit is unable to synchronize within a specified startup time following an outage or reserve shutdown.”

The in-service condition on U2 and U3 is a hard edit, not a guideline. RS to U2 is an invalid transition, flagged in NERC’s event details training module because “RS is an offline state while a U2 can only occur from an online state.” A problem found on a unit that is already off line becomes U1 or SF, never U2 or U3.

The weekend test has its own rule for problems found on Saturday or Sunday. The 2026 DRI states: “If an outage occurs before Friday at 2400 hours (or before Friday turns into Saturday), the above definition applies. But if the outage occurs after Friday at 2400 hours and before Sunday at 2400 hours (the 48 hours of Saturday and Sunday), the MO will only apply if the outage can be delayed past the next, not current, weekend. If the outage cannot be deferred, the outage shall be a forced event.”

SF has three timing elements of its own. The startup period “begin[s] with the command to start and end[s] when the unit is synchronized,” and the operating company defines its length per unit and per startup condition (cold, warm, hot). “An SF begins when a problem preventing the unit from synchronizing occurs. The SF ends when the unit is synchronized, another SF occurs, or the unit enters another permissible state.” And the preceding outage or RS must end at the exact minute the SF starts, under the DRI’s transition rule and Appendix G examples.

Synchronization is the SF boundary. The DRI states that “Problems encountered during ramp up that force the unit offline are considered outages not SF events,” and NERC’s outage event reporting module adds that “SF events can only occur offline, but an actual startup can also fail during ramp while the unit is online, which is a U1.” The reporting team uses the breaker-closure timestamp to determine which code applies.

Forced outage versus maintenance outage and planned outage

The reporting team distinguishes U3 from MO by determining whether the unit can stay in service past Sunday at 2400. If removal is required before the end of the next weekend, the event is forced. If it can be deferred beyond that but must happen before the next Planned Outage, it is a Maintenance Outage, matching IEEE 762 Class 4. A Planned Outage is scheduled well in advance with a predetermined duration and a return-to-service date fixed at the start, which is the same structure the 2026 DRI uses for planned deratings.

The DRI classifies MO as both unplanned and scheduled. The DRI notes that D4 and MO “are classified as both ‘unplanned’ and ‘scheduled.’ IEEE Standard 762 classifies these types of events as ‘unplanned.’ GADS recognizes that, historically, many operating companies referred to these events as ‘scheduled’ and continue to do so.” For calculation purposes, MO hours do not enter forced outage hours regardless of which label the plant uses internally.

Events change category when circumstances change, and the DRI sets the transition rules:

• Forced to planned or maintenance. “If the unit is on outage (for example, U1 outage due to a boiler tube leak) at the time the unit is scheduled to start the PO or MO work, then the work on the cause of the outage (tube repairs) must be completed before changing from the U1 outage to the PO or MO outage.” The PO does not begin until the forced cause is repaired.
• Planned or maintenance to forced. When the reporting team discovers unexpected problems during a PO or MO that keep the unit out past its estimated end date, the overrun is U1 rather than an extension. The U1 “must start at the same time (month/day/hour/minute) that the PO or MO ended.”
• Any outage to U1 or SF. All outage types can transition to U1 and to SF, but no outage state can transition to U2 or U3, according to NERC’s event details module.

Two timing rules require event records to have no gaps or overlaps. “When a unit moves from one outage state to another, the exact date and time that the first outage ends will be the same as when the second outage starts.” Outages can never overlap; an outage that starts during another outage produces an import error.

Forced deratings D1, D2, and D3 versus maintenance and planned deratings

A derating is a partial loss of capacity, and conventional GADS classifies it on the same urgency scale as a full outage. “Timing starts when the problem is detected,” in the words of NERC’s derate event reporting module. The 2026 DRI definitions are:

• D1, Unplanned (Forced) Derating, Immediate: “This is a derating that requires an immediate reduction in capacity.”
• D2, Unplanned (Forced) Derating, Delayed: “This is a derating that does not require an immediate reduction in capacity, but rather within six hours.”
• D3, Unplanned (Forced) Derating, Postponed: “This is a derating that can be postponed beyond six hours but requires a reduction in capacity before the end of the next weekend.”
• D4, Maintenance Derating: “This is a derating that can be deferred beyond the end of the next weekend (Sunday at 2400 or before Sunday turns into Monday) but requires a reduction in capacity before the next Planned Outage (PO). A D4 can have a flexible start date and may or may not have a predetermined duration.”
• PD, Planned Derating: “This is a derating that is scheduled well in advance and is of a predetermined duration.”

D4 has the same weekend-occurrence rule as MO: a derating that occurs between Friday 2400 and Sunday 2400 is D4 only if it can be delayed past the next weekend rather than the current one; otherwise “the derating shall be a forced derating event.”

Reporting entities must record partial-capacity loss separately from a full outage because the two enter different accumulators. A full forced outage adds its clock hours to Forced Outage Hours. A forced derating is converted first: duration in hours times MW reduction, divided by Net Maximum Capacity, according to Appendix F. D1, D2, and D3 feed Equivalent Forced Derated Hours through that conversion; D4 and PD do not enter EFDH at all.

Several recording rules apply to every derating type:

Extensions exist for the non-forced types only. A DP extends a PD and a DM extends a D4, each starting at the exact minute the original ended; when a derate runs long because of problems outside the original scope, NERC’s derate module directs: “Do not use DP or DM. Use another derate instead.”

None of this taxonomy applies to wind or solar. The 2025 Solar DRI states that it “Removed references to derates. Term was not analogous to conventional,” and wind reports subgroup turbine-hours by state rather than unit-level derates.

Extensions, reserve shutdown, and inactive states

An extension is valid only when the original scope of work runs long. The 2026 DRI defines PE as “an extension of a Planned Outage (PO) beyond its estimated completion date” and ME as “an extension of a maintenance outage (MO) beyond its estimated completion date,” and both require that the original outage had an estimated duration and return-to-service date when it began.

Three restrictions govern the choice between PE/ME and U1:

• “Use ME and PE only in instances where the original scope of work requires more time to complete than originally scheduled.”
• “Do not use ME and PE in instances where unexpected problems or conditions are discovered during the outage which render the unit out of service beyond the estimated end date of the PO or MO. Report these delays as Unplanned (Forced) Outage-Immediate (U1).”
• “Do not use ME and PE if unexpected problems occur during unit startup.”

Whichever code applies, “ME, PE or U1 must start at the same time (month/day/hour/minute) that the PO or MO ended,” and every extension must follow an outage of the same type. NERC added ME without an IEEE 762 equivalent “because ME events must be approved and tracked,” according to the outage event reporting module.

Reserve Shutdown is an available state. The unit is off line “due to lack of demand,” and it can move to U1 or SF but not to U2 or U3. RS hours count as Available Hours in the performance calculations.

Conventional units have three inactive states, each with a cause code and, for two of them, a 60-day prerequisite:

The 60-day rules are conventional-only. Wind and solar carry parallel inactive-hour categories (IRTH, MBTH, and RTH for wind; IRIH, MBIH, and RIH for solar).

What a conventional GADS event record must contain

Reporting entities submit a conventional event in the 07 format, which the 2026 DRI divides into four sections: event identification, event magnitude, primary cause, and additional cause or components worked. The required fields in the first three sections are:

Reporting entities record midnight as 2400 for the end of a day and 0000 for the start of the next. That convention matters because the system reads a one-minute gap between two events as the unit being on line, and the record then needs a T1 or T2 amplification code, according to NERC’s outage event reporting module.

Cause codes come from a set of 1,700+ four-digit codes organized by unit type in Appendices B01 through B15, according to NERC’s event details module. The Appendix D cross reference groups them by system: boiler codes run 358–1999, balance of plant 3110–3999, steam turbine 4000–4499, generator 4500–4899, gas turbine 5000–5299, and external causes 9000–9720. “Forced outages have only one primary cause,” while PO and MO events can have several.

NERC has required amplification codes for in-service U1 events since January 1, 2011. The record must carry one of three codes from Appendix J: T1 (tripped, grid separation, automatic), T2 (tripped, grid separation, manual), or 84 (unknown, investigation underway). Codes 82 and 83 (component trip, automatic or manual) apply to deratings only.

Section D is voluntary and allows up to 48 additional records numbered 04–99, each carrying its own cause code and an Event Contribution Code: 1 for primary cause, 2 for contributed to primary cause, 3 for work done during the event, and 5 for delaying the unit from reaching load after startup. Every additional record uses the event’s start and end times, so an incorrect timestamp in Section B produces errors in every downstream hour calculation and every cause-code statistic NERC publishes.

A decision table for classifying a real generation event

The table classifies each scenario against the conventional 2026 DRI definitions and gives the reasoning that the record must be able to support. Several scenarios share the same physical cause and differ only in timing or unit state:

Two rows in that table have the largest effect on the unit’s metrics: the PO overrun that must be coded U1, and the derating that is correctly D4 only if it is not actually a forced D1, D2, or D3 event. The reporting team classifies both by evaluating facts already in the outage record, namely whether the cause was in the original scope and whether the unit could have waited past Sunday at 2400.

GADS submission mechanics and quarterly reporting

Conventional event and performance data are due “within 45 days after the end of every calendar quarter throughout the life of each unit,” under the 2026 DRI, and reporting entities submit them through webE-GADS, which Open Access Technology International, Inc. (OATI) operates. Reporting entities send wind data to NERC through the GADS Wind reporting application on the same 45-day cycle. The 2026 deadlines are:

Two 2026–2027 due dates fall on weekends: November 14, 2026 is a Saturday and February 14, 2027 is a Sunday. Confirm with NERC or your Regional Entity whether the deadline shifts, and plan to submit by the preceding Friday.

Formats

webE-GADS “only accepts the 05 (Performance) and 07 (Event) GADS data file formats which have to be submitted using an import function,” according to NERC’s webE-GADS FAQ. Design data is the third data type and must precede the first event or performance submission. Wind submissions use the Excel-format XML templates on NERC’s website or an XML file following the template column order, with column headers required and no commas in filenames or field data.

Validation

webE-GADS checks data at two levels, as NERC’s GADS process module describes. Level 1 is front-end error checking that validates event and performance data as entered, so that only approved values are used and all required fields are complete. Level 2 is whole-month error checking that confirms data entered at a higher level balances month by month.

The submission workflow runs in five steps:

1. Log in to webE-GADS, open the Data > Import screen, and import the 05 and 07 files.
2. Resolve import errors.
3. Log out and wait several hours for processing.
4. Log back in, open the Checklist screen, and validate one quarter at a time.
5. Resolve validation errors. Submission is complete when the quarter is fully validated.

Step 3 is not optional. Validating before processing finishes produces the Not In Sync error the FAQ warns about.

Common reasons a submission needs correction

• Overlapping events: An outage that starts during another outage causes an error, according to NERC’s event details module.
• Invalid transitions: RS to U2 is rejected because U2 requires an online origin.
• Capacity edits: Gross Maximum Capacity must not exceed Nameplate Rating × (1 + MW Multiplier), and the FAQ states these warnings must not be ignored.
• Timing gaps: A one-minute gap between events reads as time on line and demands a T1 or T2 code.
• Missing amplification code: An in-service U1 without T1, T2, or 84 fails the edits.

Corrections and resubmissions

“Up to nine corrections and additions to an original event can be made,” using Report Revision Codes 1 through 9, and “When making corrections or additions to an original event, you need to send NERC all records relating to that event on which the changes are to be made.” NERC’s training extends this to the whole time period: “Even if just one record is revised resubmit all of the records for the revised time period.”

Deletion works differently. “Using Full Replace will delete all of the year’s data in the database and only add the data that is in the imported file,” and it is “the only way to delete records in the database,” according to the webE-GADS FAQ. The DRI recommends resubmitting the entire year-to-date dataset when deleting fields.

Consequences of late or missing data

GADS is a Section 1600 Rules of Procedure obligation rather than a Reliability Standard, so NERC does not process a late quarter through the Compliance Monitoring and Enforcement Program. Late data is worked through before it is penalized: “Your regional entity and NERC will work with your organization to accept your data, even if it is late,” (NERC’s wind GADS FAQ on penalties), and only after exhausting other options “NERC may refer an entity to FERC for non-reporting. FERC is the entity that would assess penalties.” The Section 1600 data request letter specifies that such a referral goes to FERC enforcement staff as a non-public submission, on the basis that non-compliance could violate Section 39.2(d). The market-level consequences in PJM and ISO-NE, covered below, take effect before any FERC referral.

Why forced-outage classification matters for generation performance metrics

Every U1, U2, U3, and SF hour is counted in the numerator of the unit’s forced outage rates, and no MO, PO, or D4 hour is counted. Appendix F of the 2026 DRI defines the accumulators: “Forced Outage Hours (FOH) = Sum of all hours experienced during Forced Outages (U1, U2, and U3) + Startup Failures (SF),” and Equivalent Forced Derated Hours (EFDH) is the sum of each D1, D2, and D3 event converted through the NMC formula in the derating section above, including forced deratings that occur during RS.

EFOR and EFORd

Appendix F of the 2026 DRI defines the Equivalent Forced Outage Rate as EFOR = (FOH + EFDH) / (FOH + SH + Synchronous Hours + Pumping Hours + EFDHRS) × 100%. For a conventional unit with no synchronous condensing, no pumping, and no forced deratings during reserve shutdown, this simplifies to (FOH + EFDH) / (FOH + SH), which the example below uses. Text extractions of the same appendix also show a denominator of FOH + SH + RSH, so the typeset PDF governs; the example below uses FOH + SH.

EFORd, the demand-based variant, is what PJM and NYISO consume. Appendix F defines it as EFORd = (FOHd + EFDHd) / (FOHd + SH) × 100%, with FOHd = f × FOH. The factor f is built from average forced outage duration (FOH divided by forced outage occurrences), average demand time (SH divided by actual starts), and average reserve shutdown time (RSH divided by attempted starts); PJM Manual 22 publishes it as ff = (1/r + 1/T) / (1/r + 1/T + 1/D). When RS events are reported, EFDHd = EFDH − EFDHRS, removing forced deratings that occurred while the unit was on reserve shutdown, and “NERC-GADS will use Method 2 in all its EFORd calculations.” NERC’s factors and rates module describes EFORd as the “Probability of being on forced outage or derate when demanded to run.”

Worked example

The calculation below uses EFOR with the FOH + SH denominator, a single reporting period, and the following assumptions:

• 500 MW Net Maximum Capacity.
• 6,000 Service Hours in the period.
• One 48-hour full outage after a PO ran past its estimated end date.
• One 200-hour derating of 50 MW from a cooling tower problem.
• No other events.

Choosing event codes for those two events produces these results:

The physical events are identical in all three rows. If the overrun was caused by a problem outside the original scope, the 2026 DRI requires the second or third row; if the cooling tower reduction had to be taken before the end of the next weekend, only the third row is correct.

Where accreditation methodologies use the result

PJM’s ELCC framework in Manual 21B applies a Resource Performance Adjustment of 1 − EFORd to Limited Duration Resources, Hydropower With Non-Pumped Storage, and Combination Resources. The Manual 21A methodology specifies the use of forced outage data from the October through September period before the ELCC results posting. NYISO’s Attachment J sets UCAP = (1 − AEFORd) × DMNC, where AEFORd averages six rolling 12-month EFORd values per capability period, with U1, U2, U3, and SF in FOH and D1, D2, and D3 in EFDHd. In both markets, D4 is outside the forced-derating inputs. The example uses EFOR for simplicity. NYISO calculates UCAP from AEFORd, a demand-weighted average, so the exact MW effect differs. The result is the same in both markets: every forced hour or forced derating coded as planned or maintenance overstates the unit’s UCAP for as long as that month remains in the rolling average.

NERC GADS versus ISO/RTO outage definitions

NERC GADS and ISO/RTO outage systems collect overlapping data for different purposes, and the same physical event can carry different classifications in each. Appendix M of the GADS DRI, titled “Differences between NERC-GADS and ISO-GADS Data Collection and Uses,” states that “NERC GADS is an equipment outage system with a focus on plant reliability and assessments. The ISOs are charged with the reliability of the bulk electrical grid, dispatching generating units in an economical manner, and running their electric markets.”

NERC accepts the inconsistency openly. Appendix M notes that ISOs “follow their own definitions for things like OMC events, as specified in their market rules,” and that “reporting companies in some cases have to report their GADS data as per the ISO rules rather than the NERC rules. NERC will accept either with the understanding that generating unit histories reported under the ISO rules are inconsistent with those reported under NERC rules.” The 2026 DRI adds a specific instruction for extensions: “if the extension meets the GADS rules, then report it as an ME or PE and not a U1 when reporting to GADS only.”

How the definitions and deadlines differ

The three eastern markets each define a forced outage on a different basis, and none uses NERC’s six-hour and Sunday-2400 tests as the primary definition:

PJM

PJM is the only ISO that deviates from the NERC rules; its eGADS user guide puts it as “PJM is the only ISO who deviates slightly from the NERC rules. All other ISOs conform to the NERC rules.” The main deviation is OMC: “Commencing June 1, 2018, PJM will not recognize any events as OMC. Although OMC event cause codes can be used, they will be treated as non-OMC in all calculations for the markets and reliability calculations. Data forwarded to OATI/NERC will include the original OMC cause codes.”

PJM offers “an optional service to report GADS data entered in the PJM eGADS application to OATI/NERC,” and any Capacity Market participant must report GADS data irrespective of capability. Manual 22 sets “the unit EFORd [to] 100% for any month of operation during which minimum reporting requirements are not met.” Manual 10 also cautions that eDART “is intended to be real-time and forward-looking. Data in eDART may or may not exactly align with GADS which is a backward-looking historical application,” so the GADS reporting team uses an eDART ticket time as one input when building the historical GADS record.

NYISO

NYISO rules supersede NERC GADS rules in NYISO’s own GADS training, which also states that “All outages and derates for which NYISO receives fewer than two calendar days notice will automatically be characterized as FORCED.” An event that meets NERC’s MO test can therefore be forced in NYISO’s records if the notice was late. NYISO treats Cause Code 9300 (transmission-system problems beyond the generator step-up transformer) as MO or D4 for EFORd purposes even though it is reported as U1/U2/U3 or D1/D2/D3; all other OMC codes stay in EFORd. A Generator in a Forced Outage loses ICAP eligibility at the end of the month containing the 180th day unless repair has commenced.

ISO-NE

ISO-NE’s Planning Procedure 14, Revision 0, effective March 1, 2025, administers ISO GADS and notes that “NERC only requires GADS data to be submitted quarterly, but the ISO requires all data to be submitted monthly.” Its threshold is lower than NERC’s: conventional generators of 5 MW nameplate or greater, with hydro and pumped storage at 20 MW. ISO-NE offers to act as Delegated Reporting Entity and make the quarterly NERC submission on the participant’s behalf, and OP-5 Revision 25 requires participants to categorize outages “in accordance with the NERC Generating Availability Data System (GADS) -Data Reporting Instructions and this OP.”

The same event must match across every system that records it. A unit in NYISO or ISO-NE produces monthly ISO records and a quarterly NERC record from the same events, and a unit in PJM produces eDART tickets, eGADS entries, and a NERC file, all of which must reconcile on start time, end time, and category. A generator relying on PJM forwarding or an ISO-NE DRE arrangement still owns the Section 1600 obligation and the choice of which rulebook the forwarded record follows.

Automating GADS forced-outage classification and reporting

A manual process creates two failure points. Teams reconstruct the detection time and classification after the fact, while staff re-key the same event into the ISO system, internal log, and GADS file. PowerGADS removes manual event entry and applies an automated reporting workflow to the captured data.

PowerGADS connects to PI Historian and SCADA/DCS, as well as ISO/RTO feeds, through Integ Enterprise Consulting’s 250+ native energy APIs. It captures unit events directly from control systems and eliminates manual data entry. It also generates GADS performance calculations and regulatory reports with full audit trails.

Configured workflows apply the timing and state rules described above, along with the extension and derating requirements, to captured events. The reporting team remains responsible for the operational facts that support the final classification, including detection time, unit state, and whether work fell within the original scope.

PowerGADS’s documented 200+ validation engine checks event data before the system generates reporting outputs. The product produces GADS performance calculations and regulatory reports with a full audit trail showing classification changes. If your team is still manually entering unit events and running GADS calculations by hand, PowerGADS connects directly to your control systems and automates the full reporting workflow. Most customers go live in two weeks. To see how this works against your specific fleet configuration and ISO connections, schedule a demo with the Integ team.

FAQ

These answers summarize the classification, timing, and submission rules that most often affect a conventional GADS record. Wind and solar use different reporting structures where noted.

What is the difference between U1, U2, and U3?

All three are Unplanned (Forced) Outages in the 2026 DRI, separated by how long the unit can stay on line after the problem is detected. U1 requires immediate removal; U2 allows up to six hours; U3 allows more than six hours but requires removal before Sunday at 2400. U2 and U3 apply only to a unit that is in service when the problem is found.

When is an event SF rather than U1?

SF applies when a unit that has received a start command cannot synchronize within its operating-company-defined startup period following an outage or RS. Once the breaker closes, any trip during ramp to load is U1. The preceding event ends at the exact minute the SF begins.

How does a forced outage differ from a maintenance outage?

A forced outage (U3 at the outer edge) requires the unit off line before the end of the next weekend. A Maintenance Outage can be deferred past that weekend but must occur before the next Planned Outage. When the problem is found on a Saturday or Sunday, MO applies only if the work can wait past the following weekend rather than the current one.

How does a forced outage differ from a forced derating?

A forced outage removes the whole unit from service and adds its clock hours to FOH. A forced derating (D1, D2, or D3) reduces Net Available Capacity while the unit stays on line, and it enters EFDH after conversion by duration, MW reduction, and NMC. The same immediate, six-hour, and next-weekend timing tests apply to both.

When is a new event required instead of extending the existing one?

PE and ME are permitted only when the original scope of work runs long. Problems discovered during the outage that were not in scope, and problems during startup, require a new U1 that begins at the estimated end time of the PO or MO. The same logic applies to DP and DM for deratings.

How does GADS event classification affect performance reporting?

Forced codes (U1, U2, U3, SF, D1, D2, D3) raise EFOR and EFORd; MO, PO, PE, ME, PD, and D4 do not enter those rates. In the worked example above, coding a 48-hour overrun as PE instead of U1 changed EFOR from 0.79% to zero. PJM and NYISO both use EFORd in their accreditation formulas for the resource types their manuals specify.

How does conventional GADS reporting differ from wind and solar reporting?

Conventional units report unit-level events with the U1/U2/U3/SF and D1–D4 taxonomy. Wind and solar report plant-level forced events triggered by a loss of at least 20 MW of Plant Total Installed Capacity, ending when 95% of the lost capacity returns and less than 20 MW remains unavailable, plus monthly subgroup or inverter-group hours by state. Neither renewable DRI uses derating codes, and only forced events are mandatory under the 2025 Solar DRI.

When are quarterly GADS submissions due?

Conventional and wind data are due to NERC within 45 days after each calendar quarter closes. For 2026 that means May 15, August 14, and November 14, 2026, and February 14, 2027, for the fourth quarter. ISO deadlines are separate and monthly in PJM, NYISO, and ISO-NE.

How do automated GADS systems validate event data?

Automated systems apply configured DRI edits to event data before reporting rather than waiting for import errors. PowerGADS’s documented 200+ validation engine checks captured event data and generates GADS performance calculations and regulatory reports with a full audit trail for classification changes.