How does the message visibility timeout work in SQS?
Answer out loud or in your head first, then compare.
Answer
After a message is received, SQS usually hides it for a set time so another consumer doesn't take it straight away. The message still exists. When the work is done, we delete it from the queue. If we don't, it can become available again after the time runs out.
That time is the visibility timeout. If processing takes longer, you can extend it accordingly. But its expiry doesn't kill the previous worker. So it doesn't replace protection against a repeated effect. With a Lambda handling a batch of messages, it's worth reporting which items failed, so one error doesn't cause all the successes to be retried needlessly.
Why it matters: Specific queue mechanics, once you know the basics.
Possible follow-ups: What do you do when a message comes back while the previous program is still working on it?
How did it go? Be honest — “Not yet” puts the question on your review list.
Start with
- E-P14 · What is Amazon SQS, and how is a single message handled? — AWS, Cloudflare and infrastructure
- D-P14 · Why can a message from a queue arrive a second time? — Backend, data and system design
Further reading
- AWS: Using Lambda with Amazon SQS(opens in a new tab)Docs; accessed 22.10.2026. Polling, batches, duplicates and partial batch responses.
- AWS: Amazon SQS visibility timeout(opens in a new tab)Docs; accessed 22.10.2026. Hiding a message, redelivery and extending the timeout.