VBA DisplayAlerts in Excel — Suppress Confirmation Prompts for Unattended Macros (and Why It Auto-Confirms the Dangerous Ones)

TL;DR — Application.DisplayAlerts = False tells Excel to stop showing its confirmation and warning dialogs while your macro runs, so a macro can delete a sheet or save over a file without stopping to ask a human to click OK. The catch is that it does not cancel the question — it answers it with Excel's default response, and for destructive prompts that default is "go ahead." Turn it back on the moment the risky line is done, and restore it in an error handler so a crash cannot leave alerts off while a later prompt gets auto-answered:

Sub DeleteSheetQuietly()
    Application.DisplayAlerts = False        ' Excel will not ask "are you sure?"
    On Error GoTo CleanExit                   ' so an error cannot strand alerts off
    ThisWorkbook.Worksheets("Temp").Delete    ' no prompt - Excel just deletes it
CleanExit:
    Application.DisplayAlerts = True          ' turn warnings back on right away
End Sub

Before a handful of risky operations — deleting a sheet, saving over an existing file, closing with unsaved changes — Excel stops and raises a dialog to make sure a human meant it. That is exactly the right behavior for a person clicking around, and exactly the wrong behavior for a macro that is supposed to run start to finish on its own. DisplayAlerts = False removes the interruption. This guide is built on one idea — DisplayAlerts does not silence the warning, it answers it for you with Excel's default, and for destructive prompts the default is yes. Once you see it that way, you know where it belongs (a specific prompt you own and understand) and where it is a loaded gun (blanketing a whole macro you have not audited).

What you'll learn

• The mental model — Excel asks before risky operations; this switch answers with the default
• Where the default answer is "yes, destroy it" — the prompts that turn silent and dangerous
• The rule that matters most — narrow the window to the one line that needs it, then restore
• Why DisplayAlerts = False is not error handling — a runtime error still stops your macro
• How it differs from ScreenUpdating, Calculation, and EnableEvents
• When you actually want the dialog — and reach for MsgBox instead

The mental model: Excel asks, this switch answers with the default

A small set of Excel operations are treated as "are you sure?" moments. Delete a worksheet, and Excel warns you it is permanent. SaveAs onto a filename that already exists, and it asks before overwriting. Close a workbook with unsaved edits, and it offers to save. Each of these raises a modal dialog and waits for a click.

Application.DisplayAlerts = False tells Excel to skip the dialog and proceed with its default button — the one that is pre-highlighted when the box appears. It is not hiding the box and pausing; it is picking an answer and moving on. That distinction is the whole article. You are not muting a nag, you are pre-approving a decision — and Excel's default for a delete or an overwrite is to do it.

Application.DisplayAlerts = False   ' Excel stops asking and uses the default answer
' ... the risky operation runs with no dialog ...
Application.DisplayAlerts = True    ' asking resumes

Where the default answer is "yes, destroy it"

This is the part the "turn off warning messages" tutorials skip. Here is what the suppressed default actually does:

Every one of those is a case where the warning existed to protect you, and turning it off does not make the operation safer — it makes it silent. A person would have read the box and had a chance to say no. Your macro says yes to all of them, instantly, with no record.

The rule that matters most: narrow the window, then restore

Because you are pre-approving Excel's defaults, the danger scales with how long alerts stay off and how much runs during that window. The discipline is the opposite of the performance switches, where you wrap the whole macro. With DisplayAlerts, wrap only the one operation that needs it:

' GOOD - the window is one line wide
Application.DisplayAlerts = False
ThisWorkbook.Worksheets("Temp").Delete
Application.DisplayAlerts = True
' ... the rest of the macro runs with warnings back on ...

' RISKY - alerts are off for the whole macro
Application.DisplayAlerts = False
' ... 200 lines, any of which might hit an overwrite or delete prompt ...
Application.DisplayAlerts = True

In the risky version, if any line in that block raises a "save over this file?" or "clear this range?" prompt you did not anticipate, it is answered "yes" before you ever know it happened. Keep the window tight, and still guard it with On Error GoTo CleanExit so that if the risky line itself errors, you do not leave alerts off while the next prompt in the macro gets auto-confirmed. The restore belongs in the same CleanExit label discipline the whole cluster shares — see VBA On Error.

It resets itself — but do not lean on that

Unlike Calculation and EnableEvents, which stay off until you or a restart turn them back on, DisplayAlerts resets to True automatically when your macro finishes and control returns to Excel. That sounds like it makes the restore line optional. It does not, for two reasons:

1. The damage is already done. Auto-reset happens after the macro ends. If a sheet got silently deleted at line 40, resetting alerts at line 200 does not bring it back.
2. The window is what matters, not the end. Between "turn off" and "control returns to Excel," every prompt is auto-answered. A mid-macro error that skips your restore leaves alerts off for whatever runs next in that call. Explicit restore keeps the window exactly as wide as you intended.

So treat auto-reset as a safety net for the session, not a reason to skip the line. Set it back yourself, right after the operation that needed it off.

Why it is not error handling

A common mix-up: people set DisplayAlerts = False expecting the macro to power through a runtime error — as if it suppressed all interruptions. It does not. It suppresses Excel's confirmation and warning dialogs. A genuine runtime error (a 1004 from a bad range, a type mismatch, a file not found) still raises and still stops your macro cold.

Application.DisplayAlerts = False
Workbooks.Open "C:\does-not-exist.xlsx"   ' still raises run-time error 1004 - alerts off does not help

If you want your macro to survive errors, that is On Error's job, not this one. DisplayAlerts decides whether Excel asks; On Error decides what happens when something breaks. Two different problems, two different tools.

DisplayAlerts vs the switches it is often set beside

You will see DisplayAlerts = False at the top of a macro next to ScreenUpdating and Calculation, and it is easy to file them all under "boilerplate you set to speed things up." They are not the same kind of thing:

• ScreenUpdating is cosmetic — worst case, a frozen-looking window a restart fixes.
• Calculation is about correctness of numbers — left off, it shows stale values.
• EnableEvents is about correctness of events — left off, the workbook's handlers stop firing.
• DisplayAlerts is about decisions — it makes Excel commit to destructive actions without asking.

And it is the only one that is usually self-correcting yet can do irreversible damage inside the window. The others fail loudly (frozen screen) or silently but recoverably (recalc fixes stale numbers). A sheet deleted with alerts off is just gone.

How ExcelMaster helps

DisplayAlerts is one line, but using it well means keeping the window down to the single operation that needs it, restoring it in an error handler, and never confusing it with error handling or a blanket "make my macro quiet" switch. That is a lot of judgment for a property people paste at the top of every macro.

ExcelMaster writes the careful version by default. Ask it to "delete the temp sheets without the confirmation pop-ups," and it turns alerts off around exactly those deletes, restores them in a CleanExit handler, and leaves the rest of the macro with warnings intact — so you get the unattended run without silently pre-approving every prompt Excel would have raised.

Frequently asked questions

What does Application.DisplayAlerts = False do in VBA?

It tells Excel to stop showing its confirmation and warning dialogs while your macro runs and to proceed with each dialog's default answer instead. Operations that would normally ask — deleting a sheet, overwriting a file on SaveAs, closing with unsaved changes — happen without a prompt. It does not hide runtime errors, only Excel's built-in alerts.

Do I need to set DisplayAlerts back to True?

Excel resets it to True automatically when the macro ends, so you will not leave it off across sessions. But you should still restore it explicitly, right after the operation that needed it off, because every prompt raised while it is off is auto-answered. Put the restore in an error handler (On Error GoTo CleanExit) so a mid-macro crash cannot leave alerts off for whatever runs next.

Does DisplayAlerts = False stop my macro from crashing on errors?

No. It suppresses Excel's confirmation and warning dialogs, not VBA runtime errors. A bad file path, an invalid range, or a type mismatch still raises an error and stops the macro. To handle errors, use On Error — that is a separate mechanism from DisplayAlerts.

Why did my sheet get deleted or my file overwritten with no warning?

Because DisplayAlerts = False was in effect, so Excel used the default answer for the "are you sure?" prompt — and for deleting a sheet or overwriting a file, the default is to do it. Narrow the window so alerts are only off around the single operation you intend, and turn them back on immediately afterward.

What is the difference between DisplayAlerts, ScreenUpdating, and Calculation?

They control different things. DisplayAlerts decides whether Excel asks before risky operations. ScreenUpdating stops screen repaints (cosmetic). Calculation stops formula recalculation (leaving it off shows stale numbers). They are often set together, but forgetting each one costs something very different.

Tested in

Tested in: Excel 365 (Windows 11), VBA 7.1 — last verified 2026-08-18.

Related guides: VBA StatusBar · VBA DoEvents · VBA ScreenUpdating · VBA On Error · VBA MsgBox