When an Azure Function silently does nothing, the instinct is to open the code and start reading the handler line by line. That instinct is almost always wrong. Azure Functions not triggering is rarely a logic bug, because a logic bug requires the runtime to have invoked your code in the first place, and a dead trigger means the runtime never got that far. The platform decided not to call your function at all, and the reason for that decision lives in the plumbing between the event source and the host, not in the body you wrote. Diagnosing this well means resisting the pull toward the handler and instead asking a colder question first: did the host start, is it connected to the source the trigger listens to, and is the function even enabled?
That reordering of attention is the whole game. The connection-first rule for a dead trigger states it plainly: most functions that never fire have a broken or missing trigger connection, a stopped or unhealthy host, or a disabled state, and only a small minority have a code path that throws before doing visible work. So the diagnosis runs from the outside in. You confirm the host is up, confirm the trigger has a valid connection to its source, confirm the function is enabled and discovered, and only then look at the handler. Working in that order turns a vague “nothing happens” into a specific, confirmable cause, which is the difference between an afternoon of guesswork and a five-minute fix. The mental model that makes this work is the same one behind the broader serverless execution story, and if you have not internalized how the scale controller and host cooperate, the deeper treatment in our walkthrough of how Azure Functions serverless really works is the foundation this article builds on.
What does “not triggering” actually mean inside the runtime?
A function not triggering means the Functions host either never started, never connected to the event source, or never discovered the function, so the platform had no path to invoke your code. The symptom is silence: no logs, no invocations, no errors in the handler, because the handler was never reached. The failure is upstream of your code.
To act on that, you need the model of what sits between an event and your handler. A Function app is a single deployable unit that hosts one or more functions. Inside it runs the Functions host, a process built on the WebJobs runtime, and alongside that host the platform runs a component called the scale controller. The host is what loads your function definitions, wires up each trigger to its source, and invokes your code when an event arrives. The scale controller watches event sources and decides how many host instances should exist, scaling from zero on the Consumption plan up to many instances under load. Every trigger type plugs into this model the same way: the host establishes a connection to a source (a storage queue, a blob container, a Service Bus entity, an Event Hub, a timer schedule, or an inbound HTTP route), watches that source, and calls your function when the source produces work.
This matters because each link in that chain is a place the chain can break, and a break anywhere produces the identical symptom of nothing happening. If the host cannot start, no trigger fires. If the host starts but cannot reach the source because a connection string is wrong, that trigger never fires while others might. If the function is discovered but disabled, the host skips it. If the function is not discovered at all because its definition is malformed, the host loads everything except that one function and you see no error pointing at it. The work of diagnosis is walking that chain link by link and confirming each one, rather than assuming the last link, your code, is the broken one.
The non-HTTP triggers deserve special attention because they behave least like a normal web request. An HTTP trigger fails loudly: you call a URL, you get a status code, and a 404 or a 401 or a 500 tells you something concrete. A queue, blob, Service Bus, Event Hub, or timer trigger fails quietly, because there is no caller waiting for a response. The event sits in the queue, the blob lands in the container, the schedule passes, and if the host is not watching, nothing reports the miss. Silent failure is the defining characteristic of a dead background trigger, and it is exactly why people waste time in the handler: there is no error to read, so they assume the code must be at fault. The error, when it exists, is in the host startup log or the trigger connection, and you have to go looking for it.
One more piece of the model belongs here: the storage account that the host itself depends on. A Function app uses a storage account, referenced by the application setting named AzureWebJobsStorage, for its own internal bookkeeping. The host stores trigger state, lease information for singleton execution, blob receipts that record which blobs a blob trigger has already processed, timer schedule state, and the host’s own coordination data in that account. This is not the storage your business logic reads and writes; it is the runtime’s scratch space. When that account is unreachable or its connection string is wrong, the host cannot do its internal bookkeeping, and large parts of the trigger machinery stop working even though your code is fine. A surprising share of dead-trigger incidents trace back to this single setting, which is why it earns its own root-cause section below.
How do I gather the diagnostic signal before guessing?
Before naming a cause, capture three signals: whether the host started cleanly, whether each trigger reports a healthy connection, and whether any invocation is recorded. The log stream, Application Insights, and the function’s status in the portal give you all three. Read those first, because they convert silence into a pointed clue.
The log stream is the fastest signal. In the Azure portal, opening the Function app and viewing the live log stream, or running az webapp log tail against the app, shows the host coming up in real time. A healthy host logs that the job host started, that it found a set of functions, and that each trigger is listening. The most diagnostic line in the whole runtime is the one that reports how many functions were found. If it reports that it found your functions and lists them, the host started and discovered your code. If it logs “No job functions found,” the host started but discovered nothing to run, which is a completely different problem with a completely different fix. Reading that one line first saves enormous time, because it splits the universe of causes in half immediately.
# Tail the live host log to watch startup and trigger wiring in real time
az webapp log tail --name <function-app-name> --resource-group <rg-name>
# Confirm the app is actually running and not stopped
az functionapp show --name <function-app-name> --resource-group <rg-name> \
--query "state" --output tsv
Application Insights is the deeper signal and the one to wire up before you ever need it. When a Function app is connected to Application Insights, the host writes traces, request and invocation records, dependency calls, and exceptions there. The invocation record is the key artifact: every time the host invokes a function, it writes a request entry, and the absence of any request entry for a function over a window when you expected work is direct evidence that the host never invoked it. That is the cleanest confirmation of a dead trigger you can get, because it distinguishes “the function ran and failed” from “the function never ran.” A function that runs and throws leaves an exception and a failed request; a function that never triggers leaves nothing, and that nothing is the signal.
// In Application Insights Logs, list recent invocations for a function.
// An empty result over the expected window means the trigger never fired.
requests
| where timestamp > ago(1h)
| where operation_Name == "<function-name>"
| project timestamp, success, resultCode, duration
| order by timestamp desc
// Surface host-level startup problems and trigger-binding errors
traces
| where timestamp > ago(1h)
| where severityLevel >= 2
| project timestamp, message, severityLevel
| order by timestamp desc
The function status in the portal is the third signal and the quickest of all to check. Opening the Function app, selecting Functions, and looking at the list shows each function and whether it is enabled or disabled. A disabled function is greyed out or flagged, and the host will not invoke it no matter how many events arrive. People stare at this list without registering the state, because the eye goes to the function name and skips the status column. Train yourself to read the status first. The same blade exposes the function’s integration, where the trigger and its connection setting are shown, so you can confirm the trigger points at a connection setting that actually exists in the app’s configuration.
These three signals, read in order, almost always localize the problem before you touch the handler. Host startup tells you whether the runtime is alive and whether it found your function. Application Insights tells you whether any invocation occurred. The portal status tells you whether the function is enabled and which connection its trigger expects. With those three facts in hand, the cause is usually one of a short list, and the rest of this article walks that list. If you want a place to break a trigger deliberately and watch each of these signals respond, the hands-on environment to do that safely is described later, but the discipline is the point: capture the signal, then name the cause.
Where else does the platform record the answer?
Beyond the log stream, Application Insights, and the status list, the platform keeps several other records that confirm a dead trigger, and knowing where they live shortens the hunt. The Diagnose and solve problems blade, the Kudu console, Live Metrics, and the platform metrics each expose a different angle on whether the host is healthy and whether work is flowing, so when one signal is ambiguous another usually settles it.
The Diagnose and solve problems blade is the first place to look after the log stream, because it runs the platform’s own health detectors against your app and surfaces problems you would otherwise have to infer. It flags host restarts, container recycles, storage connectivity problems, and configuration issues that affect startup, and it presents them as detected findings rather than raw logs. For a dead trigger, the most useful detectors are the ones that report on the app’s availability and on its dependency on its storage account, because a host that keeps recycling or that cannot reach its storage will show up here as a flagged condition rather than as a line you have to spot in a stream. Treating this blade as a triage step rather than a last resort often names the layer the problem lives in before you have read a single log line.
The Kudu or SCM site is the deeper instrument, the advanced tools environment attached to every app. From there you can read the host’s own log files on disk, inspect the deployed file structure to confirm the function content actually shipped, and open a console to check what the host sees. For a discovery failure this is decisive, because you can look directly at whether the compiled function content and the function metadata are present in the deployment, which answers the “No job functions found” question at its source rather than by inference. Kudu also exposes the environment the host runs in, so you can confirm the runtime and worker settings the host actually resolved at startup, which sometimes differ from what the settings blade implies when a deployment layered values in an unexpected order.
Live Metrics is the real-time signal for proving a trigger fires under a controlled test. Opening Live Metrics and then deliberately producing an event the trigger should react to, dropping a message on the queue, posting a blob, or sending to the hub, lets you watch in real time whether the host reacts within seconds. A spike in incoming requests or an appearing invocation confirms the trigger is live; a flat line confirms the host did not react. This closes the loop between cause and effect tightly, because you control the input and watch the output at the same moment, which removes the ambiguity of waiting and wondering whether an event ever arrived.
Which diagnostic surface should I check first?
Check the host log stream first, because it confirms whether the host started and how many functions it found, which splits the causes in half. Then read the Diagnose and solve problems blade for detected health issues, query Application Insights for invocation records, and use Live Metrics with a deliberate test event to prove a trigger reacts in real time.
The platform metrics round this out with counts that confirm volume. The function execution count and the function execution units are emitted as metrics, so charting them over the window in question shows whether any executions happened at all, independent of Application Insights. This is useful when Application Insights was never connected, because the execution-count metric still exists and a flat zero over a window you expected work confirms the dead trigger without any traces. Reading the metric is coarser than reading an invocation record, since it gives you a count rather than a per-invocation detail, but for the binary question of whether anything ran, the metric answers it. Between the health detectors, the Kudu file and log view, the real-time Live Metrics test, and the execution-count metric, the platform offers four independent confirmations of a dead trigger, and using more than one removes the doubt that a single ambiguous signal leaves.
The connection-first rule for a dead trigger
The single most useful idea in this whole topic is an ordering rule, and naming it makes it stick. The connection-first rule for a dead trigger says: when a function never fires, verify the trigger’s connection and the host’s health before you read a single line of the handler, because a missing or wrong connection and a stopped or disabled host account for the large majority of dead triggers, while a code bug that suppresses all output is rare. The rule is a priority order, not a claim that code is never the problem. It simply puts the cheap, high-yield checks first.
The reason the rule holds is structural. For your handler to be the cause of total silence, the host must have started, discovered the function, connected to the source, received an event, and invoked your code, and then your code must have failed so early and so quietly that it produced no log and no exception record. That is a narrow failure mode. Every link before it is both more likely to break and easier to confirm. A connection string can be missing after a deployment that did not carry settings forward. A function can be disabled by an app setting left over from a test. The host can fail to start because a runtime version was bumped underneath it. Each of those is more common than a perfectly silent handler crash, and each is confirmable in seconds. So you check them first, in the order of likelihood and confirmability, which is exactly the series habit of a directed diagnosis applied to this specific failure.
What the rule protects you from is the most expensive mistake in this domain: debugging the function body when the host never invoked it. Imagine spending an hour adding log lines to a queue-triggered function, redeploying between each change, and seeing no new logs, growing more confused, when the actual problem is that the queue connection setting names a storage account that no longer exists. Every redeploy confirmed nothing because the handler was never reached. The connection-first rule would have caught that in the first minute by checking the trigger’s connection setting against the app’s configuration. The discipline costs almost nothing and saves the worst kind of wasted effort, the kind where every action seems to fail for no reason because you are acting on the wrong layer entirely.
What should I check before reading the handler?
Check four things first: that the app is running, that the host startup log shows the function was found, that the function is enabled in the portal, and that the trigger’s connection setting exists and can reach its source. Each takes seconds and each is more likely to be the cause than a silent code crash.
The order within those four matters less than the principle of exhausting them before opening the handler. In practice the app-running check and the disabled check are the fastest, so they come first by convenience, while the host-log and connection checks are slightly more involved but more often the actual cause. What unifies them is that all four sit upstream of your code, so confirming them either finds the problem or earns you the right to suspect the handler with confidence. A handler suspected after those four checks pass is a handler worth reading, because you have ruled out the cheaper explanations and the remaining possibility, a function that triggered and failed silently, is now worth the deeper look that the invocation record will either support or refute.
Root cause one: AzureWebJobsStorage is missing or wrong
The most common single cause of broad trigger failure is a missing, wrong, or unreachable AzureWebJobsStorage setting. The host uses this storage account for its own internal coordination, and without a working connection to it, the host cannot manage trigger state, leases, or schedules, so triggers that depend on that bookkeeping stop firing even though your code is untouched.
How to confirm it is yours. Check the application settings of the Function app for a setting literally named AzureWebJobsStorage. It should hold either a full connection string for a general-purpose storage account or, in an identity-based configuration, a set of settings that point the host at a storage account it accesses through a managed identity. If the setting is absent, holds a connection string for an account that was deleted or rotated, or points at an account the host cannot reach on the network, the host bookkeeping breaks. The host startup log usually complains about storage when this happens, with messages about being unable to reach the storage account or failing to initialize, so the log stream is the fastest confirmation. The command below reads the current value so you can compare it against a known-good account.
# Inspect the AzureWebJobsStorage setting (and any trigger connection settings)
az functionapp config appsettings list \
--name <function-app-name> --resource-group <rg-name> \
--query "[?name=='AzureWebJobsStorage' || contains(name, 'Storage') || contains(name, 'ServiceBus')]" \
--output table
# Verify the host can actually reach the named storage account
az storage account show --name <storage-account-name> --resource-group <rg-name> \
--query "{name:name, provisioningState:provisioningState, network:networkRuleSet.defaultAction}" \
--output table
The tested fix is to point AzureWebJobsStorage at a healthy general-purpose storage account that the host can reach, using a current connection string or a correctly configured identity-based connection, and then restart the app so the host picks up the change. If the account exists but the host cannot reach it because the storage account firewall denies the app’s outbound traffic, the fix is on the network side: the storage account network rules must allow the app, whether through a trusted-services exception, a private endpoint reachable from the app’s integrated subnet, or a service endpoint, rather than blocking the host outright. The key is that the host’s own storage is not optional. It is the runtime’s working memory, and starving it of access produces failures that look like code problems but are infrastructure problems.
The scenarios where this bites are predictable. A slot swap that did not carry slot-specific settings can leave the production slot pointing at a storage account that was only ever provisioned for staging. An infrastructure redeploy that recreated the storage account gives it a new key, invalidating any connection string that embedded the old key, so the host suddenly cannot authenticate. A move to identity-based connections that granted the managed identity the wrong storage role, or no role, leaves the host unable to use the account even though the account exists and the network path is open. In each case the confirming check is the same: read the setting, verify the account, read the host log for storage complaints, and fix the link that is broken. Because this setting underpins blob receipts and timer schedule state and singleton leases, fixing it often restores several trigger types at once, which is a strong clue that you were looking at this root cause and not a per-function bug.
Root cause two: the trigger’s own connection is wrong or missing
After the host’s storage, the next most common cause is a wrong or missing connection for the specific trigger. A queue, blob, Service Bus, or Event Hub trigger does not hold a connection string inline; it names an application setting that holds the connection, and if that setting is absent or points at the wrong place, the host cannot connect to the source and the trigger never fires while other triggers may work fine.
This is where understanding that a binding’s connection is a setting name, not a literal value, pays off directly, and it is the same principle that governs correct binding setup generally, covered in depth in our guide to configuring Azure Functions bindings properly. A Service Bus trigger, for example, declares a connection property whose value is the name of an app setting, and the host looks up that setting to get the actual connection string or identity configuration. If the trigger declares connection: "MyServiceBusConnection" but the app has no setting by that name, the trigger silently fails to bind. There is no inline string to fall back on, so the host has nothing to connect with. The symptom is the now-familiar silence, and the fix is to add the named setting with a valid connection.
How to confirm it is yours. Read the function’s binding definition to find the name of the connection setting the trigger expects, then read the app settings to see whether a setting by exactly that name exists and holds a valid value. The names must match exactly, including case in the way the runtime resolves them, so a setting named ServiceBusConnection will not satisfy a binding that asks for ServiceBusConn. The host startup log often surfaces binding errors here, reporting that it could not find the connection or could not bind a particular trigger, which points you straight at the offending function. The integration view in the portal shows the trigger’s connection setting and whether it resolves, giving a visual confirmation without reading files.
# List the connection-bearing settings so you can match them to binding names
az functionapp config appsettings list \
--name <function-app-name> --resource-group <rg-name> \
--query "[].name" --output tsv | sort
# Set or correct a trigger connection setting, then restart to apply
az functionapp config appsettings set \
--name <function-app-name> --resource-group <rg-name> \
--settings "MyServiceBusConnection=<valid-connection-string>"
az functionapp restart --name <function-app-name> --resource-group <rg-name>
The tested fix is to align the binding’s connection name with an app setting that holds a working connection. For a Service Bus trigger that means a connection string with at least Listen rights on the entity, or an identity-based connection where the app’s managed identity holds the Azure Service Bus Data Receiver role on the namespace or entity. For a queue or blob trigger that means a storage connection setting pointing at the account that holds the queue or container, again with the right access. The common variants are a connection that points at the wrong namespace entirely, a connection string copied with Manage but not Listen rights so the host cannot receive, a Shared Access policy that was rotated so the embedded key is stale, and a move to managed identity where the role assignment was forgotten. Each produces a trigger that never fires, and each is confirmed by reading the connection and checking access against the source. Once the connection is correct and the app restarts, the trigger binds, the host begins watching the source, and the backlog of events that piled up while the trigger was dead usually starts draining, which is itself a confirmation that the fix landed.
A subtle case worth naming is the trigger that points at a real source but lacks the right authorization. The network path is open, the namespace exists, the entity is there, and yet nothing fires, because the credential can authenticate but not receive. This is the trigger analog of the broader pattern where access, not connectivity, is the wall, and it is confirmed by checking the rights on the policy or the role on the identity rather than by pinging the host. A connection that authenticates but cannot listen is functionally a dead connection from the trigger’s point of view, and the fix is to grant the receive right, not to touch the connection string’s address.
Root cause three: the function is simply disabled
A disabled function produces perfect silence and is the easiest cause to overlook because everything else looks healthy. The host starts, the connections are valid, the source has events, and still nothing fires, because the host honors the disabled flag and skips the function entirely. There is no error, because disabling a function is a deliberate state, not a fault, so the runtime has nothing to complain about.
How to confirm it is yours. Open the Functions list in the portal and read the status column for the function. A disabled function is marked as such. You can also check for a disabling app setting, because a function can be disabled through configuration as well as through the portal toggle. The setting follows the pattern of a per-function disabled flag, where an app setting named for the function with a disabled suffix, set to true, switches the function off. A function can also carry a disabled marker in its own definition. So confirmation means checking three places: the portal toggle, the app settings for a disabling entry, and the function definition itself. Any one of them being set to disabled is enough to suppress every invocation.
# Look for a per-function disabled setting that silently suppresses the trigger
az functionapp config appsettings list \
--name <function-app-name> --resource-group <rg-name> \
--query "[?contains(name, 'Disabled')].{name:name, value:value}" \
--output table
The tested fix is to enable the function: flip the portal toggle to enabled, remove or set to false any disabling app setting, and clear any disabled marker in the function definition, then redeploy or restart so the change takes effect. The reason this cause hides so well is that disabling is reversible and quiet by design, so it leaves no scar. A function disabled during a load test to stop it firing, a function disabled by a deployment template that set the flag for an environment and then promoted unchanged to another, a function someone toggled off while investigating a different incident and forgot to toggle back on, all leave the same trace, which is no trace at all. The status column is the only witness, which is why reading it first, as part of gathering the diagnostic signal, prevents an embarrassing amount of wasted investigation. When the whole app is healthy and exactly one function is silent while its siblings fire, a disabled state should be the very first thing you rule out, because it is the cleanest explanation for a single dead function in an otherwise working app.
Root cause four: the function was never discovered
Distinct from a disabled function is a function that the host never discovered, which surfaces as the “No job functions found” message or simply as a function that does not appear in the list at all. The host started, but it loaded zero functions, or it loaded every function except the one you care about, because the function’s definition is malformed, its trigger type is not recognized, or the project structure prevented discovery.
How to confirm it is yours. Read the host startup log for the count of functions found. If it reports finding no functions, the discovery problem is total and usually points at the deployment or the project structure: the compiled output is missing, the function metadata is absent, or the app is pointed at the wrong content. If it reports finding some functions but not the one you expect, the problem is specific to that function: its function.json is malformed, its binding declares a trigger type the installed extensions do not provide, or its entry point does not match the definition. The portal Functions list mirrors this, because a function that was not discovered does not appear, so a missing entry rather than a disabled entry is the tell that distinguishes this cause from the previous one.
The malformed-binding variant connects directly to the extension model. Triggers and bindings beyond the built-in HTTP and timer are supplied by extensions, and in the modern model those come through an extension bundle declared in the app’s host.json. If the bundle is missing or its version does not include the trigger type a function declares, the host cannot recognize that trigger and the function fails to load. So a Service Bus or Cosmos DB or Event Hub trigger that declares a type the installed bundle does not provide produces a function that is never discovered, with a host log that complains it cannot find a binding of that type. The fix is to ensure the extension bundle is declared and current, or that the specific extension is installed, so the trigger type resolves.
// host.json: declare an extension bundle so non-HTTP trigger types resolve.
// A missing or stale bundle is a frequent reason a trigger is never discovered.
{
"version": "2.0",
"extensionBundle": {
"id": "Microsoft.Azure.Functions.ExtensionBundle",
"version": "[4.*, 5.0.0)"
}
}
The tested fix depends on which discovery failure you have. For a total miss, confirm the deployment actually shipped the built function content, that the app’s run-from-package or deployment source points at the correct artifact, and that the project compiled, because an unbuilt or wrongly packaged app presents the host with nothing to find. For a specific miss, correct the malformed definition: fix the function.json schema, align the entry point with the function, and ensure the extension bundle provides the declared trigger type. The recurring real-world shapes are a deployment that shipped source but not the compiled output, a function.json with a typo in the binding type, a runtime that does not match the worker the code targets, and an extension bundle pinned to a version too old to include a newer trigger. Each is confirmed by the host log’s discovery report and fixed by making the definition and the deployment agree. A function that is not in the list cannot be triggered, so getting it discovered is a prerequisite to everything else, and the discovery report is the signal that tells you which side of that line you are on.
Root cause five: a runtime or worker version mismatch stops the host
A runtime-version or worker mismatch can stop the host from starting cleanly or from loading your functions, which then presents as nothing triggering. The Function app declares a runtime version and a worker runtime for your language, and if your code targets a different model than the host expects, the host either fails to start or starts without your functions, and either way no trigger fires.
How to confirm it is yours. Check the app’s configured runtime version and worker runtime against what your code was built for. The application settings expose the runtime version through the extension version setting and the language through the worker runtime setting. If your code uses a newer programming model than the configured runtime supports, or the worker runtime names a language different from what you deployed, the mismatch breaks loading. The host log is again the witness, reporting worker initialization failures or a runtime that could not load the function app, and those messages point at a version or worker problem rather than a connection problem. This cause tends to appear right after a platform change: a runtime upgrade, a migration between programming models, or a redeploy that changed the worker runtime setting.
# Read the runtime and worker settings that govern how the host loads your code
az functionapp config appsettings list \
--name <function-app-name> --resource-group <rg-name> \
--query "[?name=='FUNCTIONS_EXTENSION_VERSION' || name=='FUNCTIONS_WORKER_RUNTIME'].{name:name, value:value}" \
--output table
The tested fix is to align the configured runtime and worker with the model your code targets. That means setting the extension version to the major version your code was written for, setting the worker runtime to the language you actually deployed, and redeploying so the host and the code agree. When a platform-initiated runtime upgrade is the trigger for the incident, the fix may be to update the code to the newer model rather than to pin the runtime back, because pinning to an unsupported version only defers the problem. The judgment here is which side to move: if the code is current and the setting drifted, fix the setting; if the platform moved forward and the code is behind, move the code. The shared symptom of nothing triggering hides this entirely until you read the host log, which is why the runtime and worker settings belong on the checklist alongside the connection settings. A host that cannot load your functions because of a version mismatch is just as silent as a host that cannot reach its storage, and only the log distinguishes them.
Root cause six: the blob trigger is polling and lagging, not broken
A classic blob trigger that fires late or never is often not broken at all. It is polling. The classic blob trigger does not receive an instant push when a blob lands; it scans the container on an interval and records which blobs it has already seen, so under some conditions a new blob can wait a long time before the scan reaches it, and at scale or after a restart the lag can look like a dead trigger.
How to confirm it is yours. The signal is timing rather than total silence. Blobs eventually get processed, but with a delay that grows with the number of blobs in the container, because the polling scan has more to enumerate. New blobs in a busy container can wait noticeably, and a blob added while the host was scaled to zero may not be picked up until the host wakes and scans. If your symptom is lateness rather than nothing, and it correlates with container size or with the host having been idle, you are looking at polling latency, not a broken connection. The blob receipts the host stores in its own storage account record which blobs were processed, so a blob that was already recorded as processed will not fire again, which is another timing-shaped behavior people misread as a missed trigger.
The tested fix is to change the delivery mechanism rather than to fight the poll. The Event Grid based blob trigger replaces polling with event delivery: Azure Storage raises an event when a blob is created, Event Grid routes it to the function, and the function fires promptly without scanning the container. This removes the latency that polling imposes and scales without the enumeration cost. The alternative pattern is to decouple ingestion from processing by writing a queue message when a blob lands and triggering the function from the queue, which gives you prompt, ordered, retryable delivery and sidesteps blob polling entirely. Choosing between Event Grid delivery and a queue-based pattern is a design decision about latency, ordering, and how the blobs arrive, but either one resolves the “blob trigger fires late or never” complaint at its root, because both stop relying on a periodic scan. The misdiagnosis to avoid is expecting instant blob triggers from the classic polling trigger and concluding it is broken when it is merely slow by design. Knowing the mechanism reframes the fix from troubleshooting to architecture.
Root cause seven: the timer trigger has a wrong schedule
A timer trigger that never runs on schedule usually has a malformed or misunderstood CRON expression, a timezone assumption, or a singleton-lease problem, not a broken connection. The timer trigger fires on a schedule expressed as a six-field NCRONTAB expression, and a small mistake in that expression, or a wrong assumption about which timezone it uses, makes the timer fire at the wrong time or never at the expected one.
How to confirm it is yours. Read the timer’s schedule expression and check it field by field, remembering that the Functions NCRONTAB format includes a seconds field, so it has six fields rather than the five fields of standard cron, and an expression copied from a standard-cron source will be shifted by one field and fire at a surprising time. Then check the timezone assumption, because by default the schedule is evaluated in a platform-default timezone unless an app setting overrides it, so a job you expected at a local hour may be running at that hour in a different zone. Application Insights shows the timer’s invocations, so an empty invocation history over a window when the schedule should have fired confirms it is not running, while invocations at unexpected times confirm a schedule or timezone error rather than a dead trigger.
# Check whether a timezone override is set; absence means the platform default applies
az functionapp config appsettings list \
--name <function-app-name> --resource-group <rg-name> \
--query "[?name=='WEBSITE_TIME_ZONE' || name=='TZ'].{name:name, value:value}" \
--output table
The tested fix is to correct the expression to the six-field NCRONTAB format, set the timezone override if you need the schedule evaluated in a specific zone, and confirm the next runs land where you expect by watching the invocation records. There is a second timer-specific subtlety: on plans where the host can run multiple instances, the timer uses a singleton lease in the host’s storage account so that only one instance fires the timer rather than all of them, and if that lease cannot be acquired because the host storage is unhealthy, the timer can stall. That ties the timer back to root cause one, because a broken AzureWebJobsStorage can disable the very lease the timer depends on. The recurring shapes are a five-field expression that the runtime misreads, a schedule that is correct but in the wrong timezone, and a timer that stalls because the host storage that backs its lease is unreachable. Each is confirmed by reading the expression, the timezone setting, and the host storage health, and fixed by correcting whichever is wrong. A timer that never fires is rarely a dead connection and almost always a schedule, a timezone, or a lease, so checking those three resolves it.
Root cause eight: the host is not running or lost its settings
Underlying several of the above is the simplest cause of all: the host is not running, or it lost the settings it needs after a deployment or slot swap. A stopped Function app fires nothing. A running app whose settings were not carried forward by a deployment, a slot swap, or an infrastructure change can have every trigger pointing at a connection that no longer resolves, which presents as a fleet of dead triggers all at once.
How to confirm it is yours. Check the app’s state to confirm it is running rather than stopped, because a stopped app is the most literal explanation for nothing happening and the fastest to rule out. Then check whether the settings the triggers depend on actually exist, because the broadest version of this failure is a deployment or swap that left the running app without its connection settings. The tell for a settings-loss event is timing: everything worked until a deploy or a swap, and then multiple triggers went silent together. A single dead trigger points at that trigger’s connection; a whole app going silent at a deployment boundary points at a settings or host-level event affecting them all.
# Confirm the app is running; start it if it was stopped
az functionapp show --name <function-app-name> --resource-group <rg-name> \
--query "state" --output tsv
az functionapp start --name <function-app-name> --resource-group <rg-name>
The tested fix follows the cause. If the app was stopped, start it. If a deployment dropped settings, restore the full set of application settings the triggers need, because settings do not always travel with code and an incomplete deployment can ship the binaries while leaving the configuration behind. If a slot swap moved an app to a slot whose settings differ, reconcile the slot settings so the running slot has working connections, paying attention to which settings are marked as slot-specific and therefore do not swap. The network dimension belongs here too: an app integrated with a virtual network whose outbound rules or private DNS were changed can lose its path to the storage account or messaging namespace its triggers depend on, so a network change can silence triggers without any change to the app’s own settings. Confirming that path means checking that the app can still reach its sources over the network it is integrated with, and fixing it means restoring the route, the DNS resolution, or the firewall exception that the host needs. The host-and-settings layer is where a single change can take out many triggers, which is exactly why a sudden, broad, simultaneous silence should send you here rather than into any one function.
Why does my HTTP trigger return a 404 or 401 instead of firing?
An HTTP trigger fails loudly with a status code, which makes it the easiest trigger to diagnose because the response itself names the layer at fault. A 404 means the runtime could not route the request to a function, usually because the function was not discovered, the route does not match, or the app is serving the wrong content. A 401 means the request reached the function but the authorization level rejected it, which is a key or token problem rather than a routing one.
The 404 case maps cleanly onto the discovery and host causes already covered, just surfaced through a request rather than through silence. If calling the function URL returns a 404, the first question is whether the function exists in the portal list at all, because a function that was never discovered cannot be routed to, and the same deployment and definition checks apply. If the function exists but the route still 404s, the route template is the suspect: an HTTP trigger can declare a custom route, and a request that does not match the declared route, including the route prefix the app applies, will not reach the function. Confirming the route means reading the trigger’s route template and the app’s route prefix and comparing them against the URL you are calling. A trailing-segment mismatch or a missing route parameter produces a 404 that looks like a dead function but is really a routing miss.
The 401 case is about the authorization level the HTTP trigger declares. An HTTP trigger can require a function key, a host key, or admin access, or it can be anonymous, and a request that does not present the right key for the declared level is rejected before your code runs. So a function that works when you call it from the portal, which injects the key, but returns 401 from an external caller, is almost always a key that the caller is not sending or is sending wrong. Confirm by checking the trigger’s authorization level and whether the caller presents a valid key for that level. The fix is to align the caller with the level: send the correct function or host key, or lower the level to anonymous if the endpoint is meant to be public and protected another way. The key management blade lists the keys, so rotating a key that leaked and updating the callers is the remedy when a key is the problem rather than the level.
# List the host and function keys an HTTP trigger may require for authorization
az functionapp keys list --name <function-app-name> --resource-group <rg-name> --output table
The reason HTTP triggers belong in a dead-trigger discussion at all is that people group them with the silent triggers and expect the same investigation, when the status code already did the diagnosis. A 404 routes you to discovery and routing; a 401 routes you to keys and authorization level; a 500 routes you to a handler exception or a startup failure that the request surfaced. Reading the status code first, before reaching for logs, is the HTTP analog of the connection-first rule, because the code is the cheapest, highest-yield signal the trigger offers. The loud failure is a gift, and the mistake is to ignore it and start debugging as though the trigger were silent.
Working through the scenarios engineers actually hit
The textbook causes are clean, but real incidents arrive tangled, so walking the common shapes as patterns, each with the signal that gives it away, trains the reflex to localize fast. These are the recurring cases that show up again and again in practice, reframed as patterns you can match against your own symptom rather than as a list to memorize.
The post-deployment blackout is the most common shape. Everything worked, a deployment went out, and now several functions are silent at once. The signal is the simultaneity tied to the deployment boundary: a single trigger going quiet points at that trigger’s connection, but a fleet going quiet together points at a host-or-settings event that touched all of them. The pattern almost always resolves to settings that did not travel with the code, leaving every trigger pointing at a connection that no longer resolves, or a slot swap that moved the app onto settings that differ. The confirming move is to read whether the connection settings the triggers depend on still exist on the running app, and the fix is to restore the full settings set and to ship settings as part of the deployable unit so the next deploy cannot strip them. The lesson the pattern teaches is to read the timing first, because the breadth and the timing of the silence point at the layer faster than any single function’s log does.
The works-in-dev shape is the second pattern. A function fires perfectly in local development and then never fires once deployed. Local development uses a local settings file that supplies the connection values, and those values do not ship with the code, so the deployed app may have no connection setting at all unless it was configured separately. The signal is the environment boundary: it works where the local settings provide the connection and fails where they do not. The confirming move is to compare the local settings against the deployed app settings and find the connection that exists locally but is absent in the cloud. The fix is to provide the connection in the deployed app’s configuration, ideally through infrastructure as code so the two environments are defined the same way rather than diverging by hand. This pattern is why a function that demonstrably works on a developer’s machine can be stone dead in production with no code difference at all.
The blob-that-fires-once shape catches people who expect a blob trigger to reprocess. A blob lands, the function fires, the blob is updated or the function is redeployed, and the function does not fire again for that blob. The signal is that processing happened once and will not repeat for the same blob. The host records a receipt for each processed blob in its own storage so it does not reprocess, so a blob already recorded as processed will not fire again, which reads as a missed trigger to someone expecting every change to fire. The confirming move is to recognize the once-only behavior and to check the receipts the host keeps. The fix, when reprocessing is genuinely needed, is to change the trigger to an event-driven model that fires on the events you actually care about, or to move the blob and let a new path trigger it, rather than to conclude the trigger is broken when it is behaving exactly as designed.
Why is one function silent while the others fire normally?
When a single function is silent while its siblings keep firing, the cause is almost always specific to that one function rather than to the app: a disabled state, a connection setting unique to its trigger, a malformed definition that kept it from being discovered, or a poison-message loop on its source. A whole app going quiet points instead at the host or shared settings.
That contrast, one function versus all of them, is one of the most useful early splits in the whole diagnosis, because it tells you which layer to inspect before you run a single check. The shared layers, the host process, the host storage, and the network path, affect every trigger at once, so when they break the silence is broad. The per-function layers, the disabled flag, the specific connection setting, the function definition, affect only the one function, so when they break exactly one trigger goes quiet. Reading the breadth of the silence first routes you to the right layer, and from there the checklist row for that trigger finishes the job.
The scaled-to-zero shape is the fourth pattern and the one most often confused with a dead trigger. On a plan that scales to zero, an event arriving after an idle period waits for the host to wake before anything runs, so the first event is slow. The signal is that work resumes after a delay correlated with idle time, not that work never happens. The confirming move is to watch whether the delayed work eventually completes and whether the lateness tracks idle periods. The fix is a warmth or plan decision rather than a connection fix, which is why this pattern hands off to the cold-start treatment rather than staying in dead-trigger territory. Matching your symptom against these four shapes, the post-deployment blackout, the works-in-dev gap, the fires-once blob, and the scaled-to-zero wait, resolves a large fraction of incidents before you even open the checklist, because each shape carries its own giveaway signal.
The InsightCrunch trigger-failure checklist
The findable artifact for this article is a checklist that maps each trigger type to the connection it depends on, its most common silent failure, and the check that confirms it. Use it as the directed path the connection-first rule prescribes, working across the row for whichever trigger went silent.
| Trigger type | Connection it depends on | Most common silent failure | Confirming check |
|---|---|---|---|
| Queue (storage) | A storage connection setting named by the binding, plus a healthy AzureWebJobsStorage |
Connection setting missing or pointing at the wrong or rotated account | Read the binding’s connection name, confirm the setting exists and the account is reachable, watch the host log for storage errors |
| Blob (classic polling) | A storage connection setting, plus AzureWebJobsStorage for blob receipts |
Polling latency mistaken for failure; already-recorded receipts suppress reprocessing | Compare lateness against container size and idle time; check invocation timing in Application Insights rather than assuming a dead trigger |
| Blob (Event Grid based) | An Event Grid subscription on the storage account routing to the function | The Event Grid subscription is missing or routes to the wrong endpoint | Confirm the storage account has an event subscription targeting the function and that events are being delivered |
| Service Bus | A Service Bus connection setting with Listen rights, or an identity with the Data Receiver role | Connection has Manage but not Listen, or the identity lacks the receive role | Read the connection setting, verify Listen or the Data Receiver role on the entity, check the host log for bind errors |
| Event Hubs | An Event Hubs connection setting plus a checkpoint store in storage | Wrong connection, or a checkpoint store that the host cannot reach | Verify the connection and that the checkpoint storage is healthy and reachable |
| Timer | AzureWebJobsStorage for the singleton lease |
Six-field NCRONTAB misread, wrong timezone, or a stalled lease from unhealthy host storage | Check the expression field by field, the timezone override, and host storage health |
| HTTP | No external connection; depends only on the host running and the route | Host not started, function not discovered, or wrong route or auth level | Call the URL and read the status code; 404 means not found or not discovered, 401 means an auth-level mismatch |
The checklist is deliberately ordered so that the cheapest, highest-yield confirmation sits in the rightmost column for each row. For every trigger except HTTP, the confirming check begins with the connection and the host’s storage, because those are where the connection-first rule says to look. HTTP is the exception that proves the rule: because it fails loudly with a status code, you start from the response rather than from a connection, and the status code itself routes you to the cause. Keeping this table at hand turns the diagnosis into a lookup rather than a hunt. You identify which trigger went silent, you read across its row, and you run the confirming check, which either names your cause or sends you to the host-and-settings layer where a broad, simultaneous silence lives.
How do I confirm whether a trigger actually fired?
To prove a trigger fired, look for an invocation record, not for output. Application Insights writes a request entry for every function invocation, so a request entry over the window you care about proves the host called your function, and its absence proves it did not. Output can be suppressed by a quiet handler; an invocation record cannot be faked by silence.
This distinction is the backbone of confident diagnosis, so it deserves its own treatment. There are three states a function can be in when you suspect a problem, and they require completely different fixes, so telling them apart is the first job. The function never triggered, the function triggered and succeeded but did nothing visible, or the function triggered and failed. The invocation record separates the first from the other two. If there is no request entry, the host never invoked the function, and you are in dead-trigger territory, which means connection, host, discovery, or disabled state. If there is a request entry marked successful, the host invoked the function and it ran to completion, so a “nothing happened” complaint is about what the code did, not about triggering. If there is a request entry marked failed with an exception, the host invoked the function and the code threw, which is a code or dependency problem rather than a trigger problem. One query against the invocation records puts you in the right one of those three worlds.
// Decide which of the three states you are in for a given function
requests
| where timestamp > ago(2h)
| where operation_Name == "<function-name>"
| summarize total = count(),
succeeded = countif(success == true),
failed = countif(success == false)
// total == 0 -> never triggered (connection, host, discovery, or disabled)
// failed > 0 -> triggered and threw (code or dependency)
// succeeded > 0 with no visible effect -> ran but did nothing the caller can see
The same logic applies without Application Insights, just with coarser tools. The live log stream shows invocations as they happen, so triggering a known event and watching for any host activity tells you whether the host reacted. The Kudu environment and the host’s own logs record startup and invocation traces. The point is that you are hunting for evidence of invocation, not evidence of output, because the absence of output is consistent with all three states while the absence of invocation is consistent only with a dead trigger. People conflate these constantly, which is why so much effort goes into the handler when the invocation record would have shown the handler was never reached. Make the invocation record the first thing you query, and the connection-first rule almost enforces itself, because the record tells you whether the problem is even on the triggering side of the line.
Preventing dead triggers before they happen
Prevention for dead triggers is mostly configuration discipline plus observability, because the failures cluster around settings that drift and silence that goes unnoticed. The recurring causes are settings that did not survive a deployment, connections that authenticate but cannot listen, functions left disabled, and triggers whose silence no one watches for, and each of those has a preventive practice that costs little and saves the incident.
The first practice is to treat application settings as part of the deployable unit rather than as something configured by hand after the fact. When the AzureWebJobsStorage setting and every trigger connection setting are defined in infrastructure as code and shipped with the deployment, a deploy cannot strip them, because the deploy includes them. This removes the single largest class of dead-trigger incidents, the post-deploy silence where the binaries shipped but the configuration did not. The same discipline handles slot swaps cleanly, because slot-specific settings are declared explicitly rather than discovered during an outage, so you know in advance which settings travel and which stay pinned to a slot.
The second practice is to prefer identity-based connections with least-privilege roles over embedded connection strings, because a connection string carries an embedded secret that rotates and expires and silently invalidates the trigger when it does, while a managed identity with the correct receive or read role does not carry a secret to rotate. The trade is that you must remember to grant the role, but a role assignment is visible and auditable in a way that a key buried in a connection string is not, so the failure mode shifts from an invisible expired secret to a visible missing role assignment. When you do use connection strings, scope them to the minimum right the trigger needs, Listen for a Service Bus consumer rather than Manage, so the connection cannot do more than receive and a leaked string is less dangerous.
The fourth practice is to make trigger health part of your deployment ritual rather than something you verify only when an incident forces it. A deployment that ships a Function app should end with a deliberate confirmation that each trigger still fires, not just that the binaries deployed. For an HTTP trigger that means calling the endpoint and checking the status code. For a background trigger it means producing a known event, dropping a test message or a test blob, and confirming an invocation record appears, ideally automated as a smoke test that runs after every deploy. A smoke test that produces one event per trigger type and asserts an invocation within a short window catches the post-deployment blackout at the moment it happens, while the deploying engineer is still watching, rather than hours later when downstream data is missing. The cost is one synthetic event per trigger and one query for the resulting invocation, and the payoff is that the most common dead-trigger incident, the one introduced by a deployment that dropped a setting, surfaces inside the deployment window instead of becoming an outage. Pairing the smoke test with the absence-of-invocation alert gives you two nets: the smoke test catches breakage at deploy time, and the alert catches breakage that happens later when a key rotates or a network rule changes underneath a previously healthy trigger.
A final preventive note concerns the host’s own storage, because so many trigger mechanisms depend on it. Treat the AzureWebJobsStorage account as a first-class dependency with its own monitoring and its own protection rather than as an incidental setting. That means not pointing many unrelated apps at one shared account whose throttling or firewall change could silence all of them at once, not deleting or recreating that account without updating the connection, and not tightening its firewall without adding the exception the Function app needs. A surprising number of broad, multi-trigger outages trace to a change made to the host storage account by someone who did not know a Function app depended on it, so naming that dependency explicitly, in documentation and in monitoring, prevents the change from being made blind.
Related failures that look like a dead trigger but are not
Several adjacent failures present like a dead trigger and get misdiagnosed as one, so distinguishing them prevents you from applying the wrong fix. The closest neighbors are cold-start latency, a host that starts then fails, and a function that triggers and fails so fast it looks like it never ran. Each shares the symptom of apparent silence but has a different cause and a different fix.
Cold-start latency is the most common confusion. On a plan that scales to zero, the first event after an idle period has to wait for the host to spin up before the function runs, so the first invocation is slow and can look like a trigger that did not fire when it is merely a trigger that fired late. The distinguishing signal is that the work does eventually complete, and the delay correlates with the host having been idle, which is timing-shaped rather than total silence. This is a latency problem, not a triggering problem, and its remedies are about keeping the host warm or choosing a plan that does not scale to zero, which we treat fully in the guide to fixing slow cold starts in Azure Functions. Confusing the two leads people to chase connection settings when the trigger is working and the host is just waking up.
A host that starts and then fails is the second neighbor. The host begins to come up, logs some startup activity, and then crashes or fails to finish initializing because of a startup error in the code that runs during host or function-app initialization, a missing dependency, or a bad configuration value read at startup. This looks like a dead trigger because no function ever runs, but the cause is a startup failure rather than a connection problem, and the host log shows the host attempting to start and failing rather than starting cleanly and waiting. The fix is in the startup path, not the trigger connection, so reading the host log to see whether the host reached a healthy, listening state is what separates this from a true connection failure.
The third neighbor is a function that triggers and fails almost instantly, so quickly that a casual look sees no successful work and concludes nothing triggered. The invocation record settles this immediately, because a failed invocation still writes a request entry marked as failed with an exception, which is direct evidence the host did invoke the function. That puts you in code-or-dependency territory rather than dead-trigger territory, and the fix is in the handler or its dependencies. The throughput-shaped cousin of this, where a function fires but cannot keep up with the event rate so the backlog grows and it looks like events are being dropped, is a scaling and concurrency question rather than a triggering one, and the mechanics of how the platform scales the work are laid out in our explanation of Azure Functions scaling and concurrency. In every one of these neighbors the invocation record and the host log are the instruments that tell you which problem you actually have, which is why gathering that signal first is the habit that makes the whole diagnosis reliable.
The verdict: diagnose from the outside in
A function that never fires is a diagnosis problem before it is a fix problem, and the diagnosis has a fixed order. Confirm the host is running and started cleanly, confirm it discovered the function, confirm the function is enabled, confirm the trigger’s connection and the host’s own storage are healthy and reachable, and only then read the handler. That order is the connection-first rule, and it holds because every link before the handler is both more likely to break and faster to confirm than a perfectly silent code crash. The invocation record is the instrument that anchors the whole process, because it tells you in one query whether you are even on the triggering side of the line or whether the function ran and you are debugging behavior instead.
The causes cluster into a short, memorable set. The host’s own AzureWebJobsStorage is unhealthy, the trigger’s named connection is missing or cannot listen, the function is disabled, the function was never discovered because of a malformed definition or a stale extension bundle, a runtime or worker mismatch stops the host from loading, a blob trigger is polling and lagging rather than broken, a timer has a six-field schedule or timezone wrong, or the host is stopped or lost its settings at a deployment boundary. Each has a confirming check and a tested fix, and the trigger-failure checklist maps every trigger type to the one most likely to be yours. Prevent the recurrence by shipping settings as part of the deployment, preferring least-privilege identity connections over rotating secrets, and alerting on the absence of invocations so a dead trigger announces itself the moment it dies rather than when a downstream system finally notices the missing work. Diagnose from the outside in, trust the invocation record over the handler, and a “nothing happens” mystery becomes a five-minute, confirmable fix.
The deeper habit worth carrying away is that silence is a diagnostic state, not the absence of one. A function that does nothing is telling you something precise the moment you stop treating the quiet as a void and start treating it as a clue: the host did not start, or it started and found nothing, or it found the function and skipped it, or it connected to nothing because the connection was wrong, or it connected and could not listen. Each of those states leaves a fingerprint in the startup log, the invocation record, the status column, or the connection setting, and reading those fingerprints in order is what turns a baffling non-event into a named cause. The engineers who fix dead triggers fastest are not the ones who know the most about the handler; they are the ones who refuse to open the handler until the outside-in checks have spoken, because they have learned that the cheapest checks carry the most information and that the code is the last place to look precisely because it is the place everyone looks first.
To put this into practice against a live app, you can run the hands-on Azure labs and command library on VaultBook, where the lab environment lets you deliberately break a trigger connection, disable a function, or starve the host storage and then watch the log stream, the invocation records, and the function status respond exactly as described here, with a tested command and template library for every fix in this article. To rehearse the diagnosis itself under time pressure, work through scenario-based troubleshooting drills on ReportMedic, which presents dead-trigger scenarios that train you to apply the connection-first rule, read the right signal first, and confirm the cause before touching the handler, so the order becomes reflex rather than something you reconstruct mid-incident.
Frequently asked questions
Q: Why is my Azure Function not triggering at all?
A function that never triggers almost always has a problem upstream of your code: the host is stopped or failed to start, the trigger’s connection setting is missing or wrong, the host’s own AzureWebJobsStorage is unhealthy, the function is disabled, or it was never discovered. The connection-first rule says to confirm those in order before reading the handler. Start with the live log stream to see whether the host started and how many functions it found, then check Application Insights for any invocation record. No invocation record means the host never called your function, which puts the cause squarely in the connection, host, discovery, or disabled-state layer rather than in your logic. Working outside in localizes the cause in minutes instead of hours spent debugging code the runtime never reached.
Q: Why does my blob trigger fire late or never?
The classic blob trigger polls the container on an interval rather than receiving an instant push, so a new blob can wait before the scan reaches it, and the lag grows with the number of blobs in the container. A blob added while the host was scaled to zero waits until the host wakes and scans. This is latency by design, not a broken trigger, and the tell is that blobs eventually process with a delay that tracks container size and idle time. The fix is to change the delivery mechanism: use the Event Grid based blob trigger so Azure Storage raises an event the moment a blob lands, or write a queue message when a blob arrives and trigger from the queue. Both replace periodic scanning with prompt, event-driven delivery and remove the latency at its root rather than fighting the poll.
Q: Why is my timer trigger not running on schedule?
A timer that misfires usually has a malformed NCRONTAB expression, a timezone assumption, or a stalled singleton lease. Functions NCRONTAB uses six fields including seconds, so an expression copied from standard five-field cron is shifted and fires at a surprising time. The schedule is also evaluated in a platform-default timezone unless an app setting overrides it, so a job you expected at a local hour may run in another zone. Check the expression field by field, set the timezone override if needed, and confirm the next runs in Application Insights. On multi-instance plans the timer uses a lease in the host storage so only one instance fires, and if AzureWebJobsStorage is unhealthy the lease cannot be acquired and the timer stalls, which ties a misbehaving timer back to the host’s own storage health.
Q: Can a disabled function be why nothing triggers?
Yes, and it is the easiest cause to miss because everything else looks healthy. A disabled function is skipped by the host no matter how many events arrive, and because disabling is a deliberate state rather than a fault, it produces no error and no log. Confirm it by reading the status column in the portal Functions list, checking for a per-function disabled app setting set to true, and checking for a disabled marker in the function definition. Any one of those suppresses every invocation. When exactly one function is silent while its siblings fire normally, a disabled state should be the very first thing you rule out, because it is the cleanest single-function explanation in an otherwise working app. The fix is to enable the function and clear any disabling setting, then restart so the change takes effect.
Q: Why does a missing AzureWebJobsStorage stop triggers?
The Functions host uses the storage account named by AzureWebJobsStorage for its own internal coordination: trigger state, singleton leases, blob receipts, and timer schedule state all live there. This is the runtime’s working memory, not your application data. When that setting is absent, points at a deleted or rotated account, or names an account the host cannot reach because a firewall blocks it, the host loses the bookkeeping it needs and trigger types that depend on that state stop firing. The host startup log typically complains about storage when this happens. Because the setting underpins several trigger mechanisms at once, a broken value often takes out blob and timer triggers together, and fixing it restores several at once, which is itself a clue you were looking at this root cause rather than a per-function bug.
Q: How do I confirm whether a trigger actually fired?
Look for an invocation record, not for output. Application Insights writes a request entry for every invocation the host makes, so its presence proves the function ran and its absence proves it did not. Query the requests table filtered to your function over the window in question. A count of zero means the host never invoked the function, putting you in dead-trigger territory. A failed entry with an exception means the host did invoke it and the code threw, which is a code problem. A successful entry with no visible effect means it ran but did nothing observable. Output can be suppressed by a quiet handler, but an invocation record cannot be faked by silence, which is why it is the most reliable instrument for deciding whether the problem is even on the triggering side of the line.
Q: My Service Bus trigger does not fire even though the connection looks right. Why?
A Service Bus connection that authenticates but lacks the receive right produces a trigger that never fires, because the credential can connect but cannot listen. The network path is open and the namespace and entity exist, yet nothing arrives, because a Shared Access policy with Manage but not Listen, or a managed identity without the Azure Service Bus Data Receiver role, cannot receive messages. Confirm by checking the rights on the policy or the role on the identity rather than by testing connectivity, because connectivity is not the wall here, authorization is. The fix is to grant the receive right: add Listen to the policy or assign the Data Receiver role to the identity on the namespace or entity. A connection that can authenticate but not receive is functionally dead from the trigger’s point of view, so the access check, not the address, is what resolves it.
Q: What does “No job functions found” mean and how do I fix it?
That message means the host started but discovered zero functions to run, so the failure is in discovery or deployment rather than in any single function’s logic. The usual causes are a deployment that shipped source but not the compiled output, a run-from-package or deployment source pointing at the wrong artifact, an app whose project did not build, or a worker runtime setting that does not match the deployed code. Confirm by reading the host startup log for the function count and checking that the deployment actually carried the built function content. The fix is to make the deployment and the app agree: ship the compiled output, point the app at the correct package, and align the worker runtime with the language you deployed. Because the host found nothing, no trigger can fire until discovery succeeds, so this is a prerequisite to every other check.
Q: Why did all my triggers go silent right after a deployment?
A broad, simultaneous silence at a deployment boundary points at a host-or-settings event, not a per-function bug. Deployments do not always carry application settings with the code, so a deploy can ship binaries while leaving the configuration behind, leaving every trigger pointing at a connection that no longer resolves. A slot swap can move the app to a slot whose settings differ, and settings marked slot-specific do not travel. A network change to a VNet-integrated app can sever the path to the storage or messaging the triggers depend on. The tell is timing: everything worked until the deploy or swap, then many triggers died together. The fix is to restore the full set of settings the triggers need, reconcile slot settings, and confirm the app can still reach its sources over its network. Shipping settings as part of the deployable unit prevents the whole class.
Q: Does a runtime version mismatch stop functions from triggering?
It can, because the host has to load your functions, and if the configured runtime version or worker runtime does not match the model your code targets, the host either fails to start or starts without your functions, and either way nothing fires. The settings that govern this are the extension version and the worker runtime. A platform-initiated runtime upgrade, a migration between programming models, or a redeploy that changed the worker runtime can introduce the mismatch. Confirm by reading those settings and comparing them against what your code was built for, and read the host log for worker initialization failures. The fix is to align them: if the setting drifted and the code is current, fix the setting; if the platform moved forward and the code is behind, update the code, because pinning to an unsupported version only defers the problem. The silence is identical to a connection failure, so only the log distinguishes them.
Q: Why is my queue trigger not picking up messages?
A storage queue trigger that ignores messages usually has a connection problem or a poison-message situation. First confirm the trigger’s connection setting names an existing app setting that points at the storage account actually holding the queue, and that the host’s AzureWebJobsStorage is healthy, because the queue trigger depends on both. A connection pointing at the wrong account, or a rotated key embedded in the string, leaves the trigger watching nothing. If messages are being received but repeatedly fail, the runtime moves them to a poison queue after several attempts, which can look like messages disappearing without processing. Check the poison queue and the invocation records to tell a connection failure, where there are no invocations, from a processing failure, where there are failed invocations. The connection problem is fixed by correcting the setting; the poison-message problem is fixed in the handler or its dependencies.
Q: How do I read the host startup log to diagnose a dead trigger?
The host startup log is the single most diagnostic source for a dead trigger, so read it first through the live log stream or az webapp log tail. Look for three things in order. First, whether the host reports that the job host started, which confirms the runtime is alive. Second, the count of functions found and their names, because finding zero is a discovery problem and finding some but not yours is a definition problem with that function. Third, any binding or connection errors, which name the trigger that could not bind and point straight at a missing or wrong connection setting. A clean log that shows the host started, found your function, and is listening tells you the trigger machinery is healthy and sends you to check the source and the connection rights. The log converts silence into a specific clue, which is why it anchors the whole diagnosis.
Q: Do I need Application Insights to troubleshoot triggers?
You can troubleshoot without it using the live log stream and the host logs, but Application Insights makes the diagnosis far more reliable because it records an invocation entry for every function call, which is the cleanest evidence of whether the host invoked your function. Without it you are inferring from the log stream in real time, which works for problems happening now but is poor for intermittent or past failures. With it you can query whether any invocation occurred over any window, distinguish a never-triggered function from one that ran and threw, and watch invocation rates across a deployment to catch a trigger that went silent at the boundary. Wiring it up before you need it is the higher-value move, because the moment you are debugging a dead trigger is exactly when you most want a historical record of whether the function ever ran, and that record only exists if it was already connected.
Q: Why does my Event Hubs trigger stop consuming events?
An Event Hubs trigger depends on both a valid connection to the hub and a healthy checkpoint store, and a problem in either stops consumption. The trigger records its position using checkpoints stored in a storage account, so if that checkpoint storage is unreachable or misconfigured, the consumer cannot track or resume its position and processing stalls. Confirm the connection setting points at the right namespace with receive rights, and confirm the checkpoint storage is healthy and reachable, because a broken checkpoint store produces a stall that looks like a dead trigger but is really a coordination failure. The fix follows the broken side: correct the connection and its rights, or restore access to the checkpoint storage. Because the checkpoint store is usually backed by the same storage machinery the host relies on, an unhealthy AzureWebJobsStorage can affect Event Hubs consumption too, which is another reason the host’s storage health sits near the top of the checklist.
Q: Can a storage account firewall block my function triggers?
Yes. If the storage account that backs AzureWebJobsStorage or a storage-based trigger has its firewall set to deny by default, and the Function app’s outbound traffic is not allowed through, the host cannot reach the account it depends on and the affected triggers go silent. The network path being blocked produces the same symptom as a wrong connection string, so confirm by checking the storage account’s network rules alongside the connection setting. The fix is on the network side: allow the app through with a trusted-services exception, a private endpoint reachable from the app’s integrated subnet, or a service endpoint, rather than leaving the host locked out. This is a frequent cause when a security hardening change tightens a storage firewall without accounting for the Function app’s dependency on that same account, which is why a recent network or firewall change plus newly silent triggers is a strong signal to look here.
Q: Should I prefer identity-based connections to prevent dead triggers?
Identity-based connections remove a whole class of dead-trigger incidents because there is no embedded secret to rotate or expire. A connection string carries a key that can be rotated out from under the trigger, silently invalidating it, whereas a managed identity with the correct receive or read role keeps working as long as the role assignment stands. The trade is that you must grant the role, but a missing role assignment is visible and auditable, while an expired key buried in a connection string is invisible until the trigger dies. So the failure mode shifts from an invisible expired secret to a visible missing role, which is easier to catch and prevent. When you do use connection strings, scope them to the least right the trigger needs, such as Listen rather than Manage for a consumer, so the connection cannot do more than receive and a leaked string is less damaging. Either way, configuration discipline is what keeps triggers alive across rotations and deployments.
Q: My function works locally but not after deployment. What changed?
The usual difference is configuration, not code. Local development reads connection values from a local settings file that does not ship with the deployment, so the deployed app may have no trigger connection setting at all unless it was configured separately. The function fires locally because the local settings supply the connection, and it is silent in the cloud because the deployed app never received that value. Confirm by comparing the local settings against the deployed application settings and finding the connection that exists in one and not the other. The fix is to provide the connection in the deployed app, preferably through infrastructure as code so both environments are defined identically rather than diverging through manual configuration. This environment gap explains the common and frustrating case of a function that demonstrably works on a developer’s machine yet does nothing once deployed, with no code difference between the two.
Q: How do I tell a dead trigger apart from a function that is just slow?
Use timing and the invocation record together. A dead trigger produces no invocation record at all over the window you expected work, so a query that returns zero invocations confirms the host never called the function. A slow function produces an invocation record, just later than you wanted, so the record exists but its timestamp lags the event. If the work eventually completes and the delay correlates with the host having been idle, you are looking at cold-start latency on a scale-to-zero plan rather than a dead trigger, and the remedy is about warmth or plan choice. If no record ever appears no matter how long you wait, the trigger is genuinely dead and the cause is in the connection, host, discovery, or disabled-state layer. The single distinguishing question is whether any invocation record exists, because lateness leaves a record while a dead trigger leaves none.
Q: Can a VNet integration break my function triggers?
Yes. When a Function app is integrated with a virtual network, its outbound traffic to storage, messaging, and other dependencies flows through that network, so a change to the network can sever the path a trigger needs without any change to the app’s own settings. A modified route, a private DNS zone that no longer resolves the storage or namespace name, or an outbound rule that started blocking the dependency all leave the trigger watching a source it can no longer reach. The symptom is the familiar silence, and the tell is that it began with a network change rather than a code or settings change. Confirm by checking that the app can still resolve and reach its sources over the integrated network, paying attention to private DNS resolution for any private endpoints the dependencies use. The fix is to restore the route, the DNS resolution, or the firewall exception, because the connection setting is correct and only the path beneath it broke.
You have put in real work getting to the bottom of this, and that kind of methodical troubleshooting is exactly the mindset that pays off everywhere. Keep at it. And while you are giving your code the outside-in treatment, give yourself the same care: get a solid workout in, move that body, and you will feel as sharp and as good as your freshly fixed triggers look. You deserve to look and feel great.