Your EventBridge Target DLQ Is Empty. Did Lambda Finish?

Distinguish Classic EventBridge target delivery from Lambda asynchronous processing and failed capture before drawing conclusions from an empty dead-letter queue.

No. An empty EventBridge target dead-letter queue does not prove Lambda finished the work. That queue captures events EventBridge could not deliver to the configured target. An accepted asynchronous handoff can be followed by a Lambda processing failure, an event expiring before the handler runs, or a failure to retain the failure record itself. None of those is an accepted business result.

The practical task is to identify which boundary your evidence describes. This article supplies a failure-boundary worksheet for one Classic EventBridge event-bus rule with one direct standard Lambda target in one account and Region. All worked records are fictional and NOT EXECUTED. No AWS configuration, queue, function, log or metric was queried or changed.

1. Establish the integration before applying the model

Record the exact API/resource type, rule ARN, target ID and target ARN, including any Lambda alias or version qualifier. Retain a dated configuration reference and the deployed function mode. An operator looking at another alias's async settings has not established this target's behavior. A synchronous console test is not evidence for the EventBridge invocation path.

The Classic Target API identifies the target and its input, retry and dead-letter configuration. Preserve Input, InputPath or InputTransformer behavior as applicable. A transformer can omit the original event identifier; nearby timestamps do not restore a reliable event-to-invocation join.

AWS's April 2023 asynchronous error-handling explanation explicitly describes EventBridge invoking Lambda asynchronously. This is the narrow Classic direct-target model used here, paired with current rule and Lambda async references. It is not a claim about every interface bearing the EventBridge name. The current custom-bus subscriber Lambda reference separately exposes EVENT and REQUEST_RESPONSE modes and batched input. Do not import those options into the Classic Target API or assume this worksheet covers that interface.

Scheduler, Pipes, SQS event source mappings, subscriber APIs, managed-instance and durable or multi-tenant variants, cross-account/Region paths and encrypted event-bus DLQs are outside this scope. If exact identity or invocation applicability is missing or conflicting, stop at UNKNOWN and ask its owner to resolve that input. Do not diagnose the wrong product more confidently.

2. Ask whether EventBridge delivered to the target

EventBridge's target DLQ documentation defines this collector for events not delivered to a target. It uses a standard SQS queue in the same Region. Delivery metadata can identify the rule, target, error and retry context. Some failures, including missing target permissions or a nonexistent target, can go directly to the DLQ without delivery retries.

For retriable delivery errors, the rule retry reference documents a default of 24 hours and up to 185 retries with backoff and jitter. Record the actual configured age and retry limits. The default is neither the customer's setting nor a guarantee that every failure receives every attempt. It does not describe retries of code that has already been handed to Lambda.

An empty collector can have several explanations: no relevant undelivered events, no configured collector, an unsuccessful write to it, consumed or expired messages, a wrong queue, or an incomplete observation. Preserve the observation method and time window. Do not receive messages merely to inspect an incident without authorization: reading a queue can change visibility and interfere with its consumer.

3. Separate Lambda queue admission from processing

The Lambda asynchronous invocation guide describes admission to a Lambda-managed queue before function processing. Acceptance is a handoff, not a successful handler result. The queue is not a customer SQS queue, and this article does not invent an acceptance receipt from an AWS run.

Lambda's async error-handling guide distinguishes function errors from throttling and system failures. By default, function errors receive two additional attempts, with waits of one and two minutes. Throttling and system errors have different backoff/queue-age handling, documented by default up to six hours. Events can expire before processing; duplicate deliveries can also occur. Therefore, a missing handler log is not automatically evidence of a code exception.

Record the target's applicable async configuration, not just defaults. Do not add the EventBridge and Lambda default ages into a supposed end-to-end completion deadline. They belong to separate failure domains, with different configurations and error classes. Neither establishes a business deadline or permits replay.

*Illustrative applicable async path, not captured execution. Blue arrows show handoff and processing direction; brown dashed branches show conditional failure capture. The selected Lambda OnFailure destination is generic because its deployed type is UNKNOWN. It is not the EventBridge DLQ. Business completion needs separate evidence, not an arrow asserting success.*

4. Identify the actual Lambda failure collector

The current retaining-records guide distinguishes an OnFailure destination's invocation record, including request and response context, from a Lambda DLQ's original event plus attributes. A destination can be configured for a function, version or alias. Lambda DLQ settings are function-level; versions use the unpublished version's DLQ settings. Record the collector actually configured, its scope and its expected record shape. Do not assume two similarly named queues receive the same content.

Failure capture itself has an owner. EventBridge reports InvocationsSentToDLQ and InvocationsFailedToBeSentToDLQ; Lambda's metric definitions include DestinationDeliveryFailures and DeadLetterErrors. A failed capture attempt is compatible with an empty collector. It is a separate problem from why delivery or processing failed. Configuration, authority and applicable service limits need their own approved readback, not an immediate broad permission grant.

Metrics are supporting signals, not per-event receipts. AsyncEventsReceived counts successful admission to Lambda's async queue; Errors concerns failed invocations. Retries and other sources can contribute to aggregates. Keep dimensions, statistic, period, UTC range and completeness with each query. Do not subtract these totals to manufacture the number of completed business operations.

5. Complete a fictional boundary worksheet

Every row below stipulates applicable Classic async scope and permitted metadata sources unless it explicitly says otherwise. Identifiers A through G are local examples, not AWS event IDs. “Correlated” means that a retained safe identifier and exact target/qualifier are stipulated to match. Capture settings and observations must be obtained again for a real case.

For a completed example, packet B names hypothetical rule rule-R, target target-T and alias worker:stable, with a dated revision reference and safe operation token fixture-B. It stipulates that the input transform retained that token, an async acceptance reference exists, and the OnFailure record for the same qualifier records exhausted handler attempts. The target-DLQ observation covers a stipulated window but is not the deciding evidence. Its output is “processing failure, function owner investigates,” with business result UNKNOWN and no replay authority. Actual configured retry values and all real identifiers are still UNKNOWN outside the fictional packet.

Packet F cannot become packet B merely because the error chart overlaps an incident timestamp. Packet G cannot become completed work merely because the handler returned. If recovery requires a business decision, hand off to the existing dead-letter business reconciliation guide, which owns replay eligibility and uncertain effects. This article does not redrive either queue.

6. Copy a blank record and preserve the gaps

Record ID / UTC observation window / evidence owner / collector authority:
Exact EventBridge API and resource type / account / Region / revision:
Classic rule ARN / target ID / target ARN / Lambda qualifier and revision:
Deployed function mode / async applicability evidence or UNKNOWN:
Input transformation / safe event identifier / business-operation identifier:
Correlation preserved? source reference, limitation or UNKNOWN:
Actual EventBridge delivery age/retries / target-DLQ ARN or absent/UNKNOWN:
Delivery record reference / queue-observation method and limitations:
Lambda qualifier-specific async age/retries / OnFailure destination:
Function-level Lambda DLQ setting / retained record shape:
Queue admission / processing / expiration evidence, each separately:
Metrics: namespace/dimensions/statistic/period/UTC window/completeness:
Failure-capture configuration/authority/result references or UNKNOWN:
Business accepted-result reference or UNKNOWN:
Boundary conclusion / missing inputs / next bounded action and owner:
Stop condition / recheck trigger / recovery authority NOT ESTABLISHED:

Use approved existing metadata and references. Invocation records can contain payloads and responses; do not copy them into a public incident note or collect secrets to improve a join. Store exact identifiers in the authorized evidence location and share aliases where appropriate. A denied read leaves an input UNKNOWN; it is not proof the setting or event is absent. New logging, paid queries, permission changes, invocations and capture infrastructure need separate authorization.

7. Hand off the failure boundary, not a green dashboard

Start with one incident and complete the blank record above using already-authorized evidence. Mark unsupported joins UNKNOWN, name the owner of each missing fact, and hand off the record before considering replay or configuration changes.

The useful output is one scoped record: the integration is applicable, the observed failure belongs to a named boundary, capture limitations are explicit, and the next owner knows which missing fact to obtain. If the integration or join is not established, UNKNOWN is the output. No empty-queue shortcut changes that.

Recheck after rule targets, input transforms, alias routing, function revisions, async settings, collectors or observation windows change. Keep recovery and implementation separate. The serverless production guide owns the SQS-consumer design, while the event-driven scaling playbook owns outbox, duplicate effects and replay design. This narrower worksheet gets the incident to the right evidence owner without claiming delivery is processing, capture is guaranteed, or successful code is completed business work.