How to File and Clear a NOTAM for a Tower Light Outage
This is a subtitle for your new post

If your tower’s obstruction lighting is required and something goes out, the goal is simple: restore the lighting and close the loop cleanly. The best outcomes come from a repeatable workflow that starts with good documentation and ends with confirmed resolution.
If you’re not sure what a NOTAM is, start here:
What Is a NOTAM (and Why Tower Owners Should Care) ?
Need help building a consistent outage/NOTAM workflow? Book a Call .
First: confirm who is responsible (owner vs. operator vs. vendor)
Before “filing” anything, confirm who is responsible for origination and cancellation/closure within your organization’s process. FAA policy emphasizes that the party originating the NOTAM is responsible for accuracy and cancellation/closure actions.
What you need before you file (gather this first )
Structure details (ASR-first, plus ASN for FAA workflows)
• FCC ASR number (primary identifier)
• Site/tower name (owner naming or your naming convention)
• Location (address and/or coordinates)
• Height (as documented)
• FAA Aeronautical Study Number (ASN) (often needed for OE/AAA E-file actions)
Why both? ASR is the most common operational identifier for tower owners/operators. But the FAA OE/AAA E-file NOTAM workflow in the Desk Reference Guide is driven by ASN.
Outage details
• What’s out (top beacon, side markers, multiple levels, controller behavior)
• When it was first detected (date/time + timezone)
• Whether it’s continuous or intermittent
• What triggered detection (alarm/monitoring vs. visual confirmation)
Repair plan
• Who is dispatched
• Estimated time to restore (if known)
• Any access constraints (site access, climb requirements, weather delays)
Contact + recordkeeping
• Primary point of contact
• Incident log entry (one place where all updates live)
Want a predictable process for monitoring + documentation + response? We can help .
Filing the NOTAM: Two Common Paths
Path A: Your internal / vendor workflow (general)
Use your established reporting workflow (owner-managed, vendor-managed, or LumenServe-managed). Keep the incident record current and make sure the administrative closeout is confirmed—not assumed.
Path B: FAA OE/AAA “NOTAM E-Notification” via E-file (when required by your FAA determination)
If your FAA determination requires NOTAM notification via the OE/AAA process, the FAA Desk Reference Guide indicates this is completed through a registered E-file account.
High-level steps (as described in the guide):
1. In your OE/AAA portal, use the Temporary Structure Notification link (under “Off Airport Construction”).
2. Enter the Aeronautical Study Number (ASN) and confirm the case details.
3. Add the supplemental notice (shown as “Add 7460-2”), then select “Request a NOTAM.”
4. Provide the required fields the guide calls out (start date; completion date or number of days; removal date; time of arrival; onsite contact + phone). The guide notes the removal date cannot be in the future.
5. Save/confirm to submit.
Important note from the guide: You may also need to complete separate notification to the airport and/or air traffic control tower depending on the conditions in your FAA determination letter.
Clearing/Canceling: What “Done” Means
Clearing is where teams stumble—because the lights might be back on, but the administrative loop isn’t finished.
1) Verify restoration (don’t assume)
Confirm the lighting system is operating correctly (visual when safe, monitoring, and/or technician documentation).
2) Document proof of restoration
Log restoration time, what changed, how it was verified, and who verified.
3) Close/cancel through the same workflow you used to initiate
In the OE/AAA E-file workflow, the Desk Reference Guide includes a NOTAM Cancellation Notification path and again notes the removal date cannot be a future date.
4) Confirm closure and record it
Whatever method you use, don’t stop at “we fixed it.” Record the closure confirmation in your incident log.
Want LumenServe to help operationalize this so it’s consistent every time? Book a Call.
Common mistakes to avoid
• Not capturing detection time consistently
• Vague outage descriptions
• No single owner accountable for closure
• Assuming “restored” automatically equals “cleared”
• Thin documentation






