> ## Documentation Index > Fetch the complete documentation index at: https://docs.tied.com/llms.txt > Use this file to discover all available pages before exploring further. # Auto-resolve conversations > Closing conversations after inactivity. Auto-resolve is a housekeeping feature, not a support outcome, and the billing rule below exists specifically to keep those two things from getting confused. ## What it does This is an account-wide setting, not a per-inbox one. After a chosen number of minutes with no activity, an open conversation is flipped to resolved on Tied's next sweep — not at the exact minute the threshold passes. Two things are optional on top of that: * **Ignore waiting, or respect it — and the default is the one to worry about.** By default `auto_resolve_ignore_waiting` is off, and Tied resolves every stale open conversation on the inactivity clock alone, regardless of who was supposed to reply next — including one where the customer is waiting on *you* and hasn't heard back. Turn the setting on and that protection kicks in: Tied stops auto-resolving a conversation for as long as it is waiting on your reply. `waiting_since` is stamped the moment a customer's message comes in and cleared the moment a human replies — while it's set, the inactivity sweep leaves the conversation alone. * **A closing message and a label.** Send a message announcing the auto-resolution — skipped, and logged as skipped, if the channel's messaging window has already closed — and apply a label so these are easy to tell apart from conversations a person actually closed. This sits behind the `auto_resolve_conversations` flag, which is on by default. ## The billing consequence **An auto-close is a timeout, not a signal, so it does not produce a billable resolution.** It is not the customer confirming anything, not a system proving anything, and closing a conversation is not one of the four things that counts as a Tier 3 corroborator either. This is the same "silence never bills" rule that governs every other quiet ending — see [What counts as a resolution](/pricing/resolutions). This works in one direction only. If a real signal already existed earlier in the same conversation — an explicit confirmation, a verified system outcome, a corroborated silence with a genuine corroborator — the timeout closing the conversation afterward does not erase that. What a timeout cannot do is manufacture a signal that was never there. ## Why the setting exists at all The value is entirely operational. Without it, the inbox fills with conversations nobody is coming back to, all sitting open. The label and message make the difference visible later — "this went quiet" reads differently from "someone resolved this" when you scroll back through a thread, which matters given Tied threads by person rather than by ticket. See [Inbox](/inbox). ## Next The full signal-tier model this page's billing rule is drawn from. The opposite failure mode — a real signal that retroactively removes a charge. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.