Troubleshooting “Pilot Not Proven” Shutdowns: First-Out, Signal Margin, and Prevention

A post-trip workflow for pilot not proven shutdown events matters most when the same unit trips again. That’s when the real cost hits: lost runtime, repeat callouts, and time spent re-checking the same basics. Resets and retries can get you running, but they can also wipe the context you need to stop the pattern.

This pilot not proven post-trip workflow is built to help you get back to safe uptime faster and keep it there. It stays focused on what the system used to make the shutdown decision: first-out, signal margin and signal stability, and time-to-prove. If you capture those consistently, you can sort ignition vs detection vs stability quickly, fix the right thing first, and reduce repeat nuisance trips without compromising the safety interlocks and safety functions in your burner management systems.

What to do after a pilot not proven shutdown?

After a pilot not proven shutdown, your best move is to follow a consistent order:

1. Capture evidence before resets: capture alarms, timestamps, burner state, first-out, and conditions before reset.
2. Classify the event: ignition vs detection vs stability.
3. Verify margin: verify signal margin and signal stability through the proving window.
4. Inspect by detector type: inspect likely causes based on detector type and pilot stability indicators.
5. Restart and confirm improvement: restart in a controlled way and confirm time-to-prove and stability improvement.

That order keeps you from chasing the wrong subsystem and helps you avoid losing the most useful data. If you’re short on time, don’t skip Step 1. If you only capture two things, make it first-out and time-to-prove.

ATTENTION: Safety boundaries you shouldn’t cross

A pilot not proven trip is a protective outcome of burner management system safety functions and safety interlocks. Do not bypass interlocks or force operation to get through a shift.

If bypassing is ever permitted, it should only happen under authorized site procedure and senior authorization.

What to capture before you reset a pilot not proven shutdown?

Before you reset a pilot not proven shutdown, capture what you can’t recreate later: first-out, sequence state, signal behavior, and time-to-prove, plus the conditions that can swing proving behavior between starts. If your system has burner diagnostics, capture those logs too while they’re still tied to the original event.

Start with alarms and timestamps, plus burner state at shutdown (startup step, recycle count, lockout status). If your system provides first-out, document it. Then note what was different about this start: wind and draft changes, heater door leakage, process swings, and any recent maintenance.

If your system exposes more detail, capture it while it’s still available. Flame signal values or status, time-to-prove, re-cycle history, and any burner diagnostics logs help you separate “no ignition” from “weak proof” early. When your site practice supports it, documenting pilot pressure during lightoff and taking a quick photo of the detector or rod sighting can save you time later, especially if the issue needs escalation.

You don’t need perfect documentation. You need the same evidence set every time.

First-out: what it is and why does it matter?

First-out is the earliest protective input that started the shutdown sequence. It matters because once the shutdown begins, conditions change fast and the alarm list gets noisy. Valves change state, airflow changes, and retries can add effects that weren’t part of the original trigger.

First-out tells you what triggered the shutdown first, before the sequence started reacting. That gives your team one shared starting point, whether you’re in the field, the control room, or reviewing the event later.

Troubleshooting pilot not proven shutdowns: a step-by-step workflow

Use the steps below to keep your response consistent across field techs, operations, and engineering. Each step sets up the next one.

Step 1 — Capture evidence before anything resets

Capture the decision moment first: alarms, timestamps, burner state, and first-out. Then add the context that often exposes a marginal system: draft swings, door leakage, process upsets, and recent maintenance.

If signal data is available, record flame signal, time-to-prove, recycle count, and any burner diagnostics logs. If your site practice supports it, record pilot pressure during lightoff and take a quick photo of the detector or rod sighting. Those two details often settle the question of “pilot delivery” vs “detector acceptance” quickly.

Step 2 — Decide whether it’s ignition, detection, or stability

A pilot not proven shutdown is an outcome that’s often the result of an ignition, detection, or stability issue. But it doesn’t tell you what failed. Your job is to determine which path you’re on before you start swapping parts.

Use three questions:

1. Did the pilot ignite during PTFI (Pilot Trial for Ignition)?
2. If it ignited, was flame detected?
3. If it was detected, did the signal stay stable through the proving window, or drop out?

From there:

• No ignition confirmed: stay on ignition energy, pilot fuel delivery and pressure, restrictions, ignition timing, and pilot assembly condition.
• Ignition confirmed, but not detected: move to the detector path and signal margin (position/sighting, grounding/bonding, optics, wiring, interference).
• Detected, then drops out: move to stability drivers (pilot stability, draft swings, discrimination/viewing, marginal signal path).

A practical reminder: repeat proving problems often trace back to five failure modes. These are: no ignition (pilot never lights), late ignition (pilot lights too slowly to prove), flame is present but not detected (signal problem), unstable pilot/dropout during proving, and discrimination/viewing problems (scanner sees the wrong thing or can’t see the right thing). Avoid blaming the BMS or a coil before confirming ignition, pressure, and detector position. If you can align the classification first, the fix usually comes faster.

What does Pilot Trial for Ignition (PTFI) mean? Pilot Trial for Ignition (PTFI) is the allowed time it takes to light and prove the pilot.

Step 3 — Check signal margin, not just “is it reading”

Weak margin is a common reason pilot not proven events repeat because the signal exists, but it doesn’t meet acceptance reliably through the proving window. A present/absent check won’t catch borderline behavior.

Look for patterns over time: signal hovering near the proving threshold/limit, drift during warm-up, and dropouts during draft swings or airflow changes. If you have history, check whether it repeats across starts.

Use a baseline method instead of universal numbers. Take the last few successful startups on that asset as your reference for time-to-prove and signal behavior. If time-to-prove consistently stretches or the signal becomes unstable, treat it as margin until you rule it out. That approach keeps you focused on what’s reducing margin, rather than guessing at components.

Step 4 — Inspect based on detector type (high-level)

Now let the detection method drive your first checks. It narrows the likely causes and keeps troubleshooting proportional.

• Rectification (flame rod/µA): start with the return path, rod condition/position, and wiring/terminations. Long lead runs can introduce cable effects, including capacitive loading, so run-length and routing guidance matters.
• UV scanners: treat it as optics and sighting first. UV proving is most reliable when aimed at the stable flame root near the nozzle/anchoring point. In dirty or wet service, continuous purge flow can reduce repeat fouling and dropouts.
• IR scanners: treat it as discrimination first. Exclude glowing refractory, hot surfaces, reflections, and adjacent flame sources. Warm-up failures often point to background IR interference as surrounding surfaces heat up.
• Integrated ignition/rectification assemblies: separate ignition from proving. No spark and arcing inside porcelain are common ignition-hardware signatures. A good spark still doesn’t guarantee stable proving once the pilot lights.

If the pattern feels familiar, it usually is. Rectification issues that appear after maintenance often trace back to rod position, return path, or wiring changes. UV that improves after cleaning usually points to optics, sighting, or purge. IR that gets worse often points to background interference or sightline contamination.

One settings guardrail to consider: very limited retry settings can turn marginal conditions into frequent lockouts. Review retry behavior under your site standards and MOC. Fix margin first. Don’t “solve” proving by loosening acceptance.

Step 5 — Restart, then confirm the fix with baselines

After corrective action, restart in a controlled way and verify improvement. A pass once isn’t the same as a fix.

Confirm time-to-prove improves (or returns to normal for that asset). Confirm the flame signal stays stable through the proving window, not just a brief spike. Then document what changed, why it was done, and what improved. That record helps your crew avoid re-learning the same issue and supports faster decisions the next time a similar event shows up.

Key takeaways from the workflow

• Capture first-out, time-to-prove, and signal behavior before any reset or retry.
• Classify the event first (ignition vs detection vs stability) so you don’t troubleshoot the wrong subsystem.
• Treat repeat events as a margin problem until you rule it out with baseline comparisons.
• Confirm the fix with a controlled restart and improved time-to-prove and signal stability.

Field triage checklist for a pilot not proven trip

If you need a fast response in the field, use this list to keep the basics consistent.

• Identify the detection method (rectification, UV, or IR).
• Confirm whether the pilot ignited using approved indicators per your site practice.
• Check signal margin and signal stability, not only if it’s present/absent.
• Inspect the usual suspects for that sensor type:
  • Rectification: rod condition/position, grounding/bonding return path, wiring/terminations
  • UV/IR: optics cleanliness, sighting and sight pipe condition, purge air (if used), background interference
• Record time-to-prove and recycle counts (if available) for trending.
• Keep boundaries intact: no bypassing safety interlocks. Use qualified personnel and follow site procedures.

How to prevent repeat pilot not proven shutdowns

Preventing repeats is mostly about protecting margin over time. Optics foul, grounding loosens, pilot components wear, and draft shifts. The unit may still start for a while, then the same nuisance trip shows up again.

Broad industrial O&M data shows that condition-based/predictive programs can reduce downtime by 35-45%, which is why trending time-to-prove and signal stability—and fixing margin early—pays back quickly.

Two baselines catch drift early and make corrective work measurable:

• Time-to-prove: drift is an early warning that ignition timing, pilot quality, airflow/draft, or detection margin is changing.
• Signal strength and stability: stable signals tolerate variability; borderline signals create nuisance trips.

Routine work doesn’t need a long checklist. It needs to protect margin. Keep your focus on optics cleanliness and sighting (UV/IR), grounding/bonding and rod condition (rectification), and pilot assembly condition (orifice, mixing, plus indicators of weak ignition or poor draft). Many teams use a 3–6 month interval in harsh service, then adjust based on what your site actually sees. Preventative maintenance can lead to 12% to 18% cost savings over a reactive maintenance program.

Read about Why Preventative Maintenance is Important in Industrial Heating Operations.

Key troubleshooting takeaways for preventing repeats

• Trend time-to-prove and signal stability on each asset, not just pass/fail.
• Fix margin drivers early (sighting, optics, grounding/bonding, pilot stability).
• Use the same workflow across heaters and boilers so trends and troubleshooting are comparable.

Close the loop: keep the evidence consistent

Capture first-out and signal data before resets. Classify ignition vs detection vs stability. Confirm signal margin through the proving window. Then validate improvement with time-to-prove and signal stability. Repeat trips drop when you keep the evidence consistent and you can see the baseline move in the right direction.

Related:

• Common Burner Trips in Combustion Appliances
• Pilot Flame Not Proven Trips in Burner Management Systems: 5 Failure Modes and What to Check
• Understanding Flame Detection Methods: Flame Rods vs UV Scanners vs IR Scanners

Frequently Asked Questions About Pilot Not Proven Trip Troubleshooting

What should I capture before resetting after a pilot not proven trip?

Capture alarms, timestamps, burner state (startup step, recycle count, lockout status), and first-out if available. If the system provides it, capture flame signal values or status, time-to-prove, recycle history, and any burner diagnostics logs. Add operating context like wind and draft changes and recent maintenance.

What is first-out and why does it matter?

First-out is the earliest protective input that started the shutdown sequence. It matters because it anchors you to what happened first, before shutdown and retries change other conditions and permissives.

What should we trend to prevent repeat nuisance trips?

Trend time-to-prove and signal margin or signal stability. Time-to-prove catches drift early. Signal stability shows whether you have enough margin to tolerate normal variability.

When should we escalate and what evidence should we bring?

Escalate when you see a repeatable pattern but corrections don’t improve time-to-prove or signal stability. Provide the following details to your service tech:

• first-out and alarm history,
• flame signal data during the proving window,
• time-to-prove trend (recent good vs recent failed starts),
• recycle counts,
• burner diagnostics logs,
• operating conditions (draft and wind),
• pilot pressure during lightoff if available,
• photos of detector or rod sighting and pilot assembly condition,
• and notes on recent maintenance plus whether it’s cold-only, hot-only, or inconsistent.