Providing Timely Updates During Incidents
Post periodic update reminders as private ticket comments for critical incidents and escalations using recurring automations and reset delays
When a critical incident lands, two things happen at once: the on-call team dives into fixing it, and stakeholders — other teams, leadership, and the customer — start expecting regular updates. The firefighting gets all the attention, updates get forgotten, and customers perceive silence reads as "nothing is happening."
This guide shows how to keep updates flowing by posting a periodic reminder as a private comment on the ticket/request whenever a critical incident goes quiet. It uses Recurring Automations and Reset Delay, so the reminder repeats on a cadence, leaves the team alone while they're actively working, and stops on its own when the incident is resolved.
Related: If you want to page on-call engineers when an incident starts, see Paging Critical Incidents to PagerDuty. This guide picks up once the incident is live — keeping the team honest about updates until it's resolved.
How it works
Every couple of hours while a critical ticket is open, the automation posts a private comment reminding the assignee to share an update — but only if the ticket has gone quiet. If responders are actively posting (investigating, sharing progress), the timer resets and the reminder holds off.
Create a new automation under More → Automate → Create Automation:
When (Trigger)
Ticket Updated
If (Condition)
Priority is one of [Critical, Urgent] and Status is Open
Delay
Wait for: 2 hours
Reset delay on: Message from a responder
Cancel on: Priority & Status field changes
Then (Action)
Send Message → private comment
Re-enqueue on completion
✅ Enabled
Step-by-step setup
1. Trigger. Set the trigger to Ticket Updated. This captures the moment an incident gets escalated to a critical priority.
2. Condition. Add a condition so the reminder only applies to live incidents: Priority is one of [Critical, Urgent] and Status is Open. Use whatever values match your configuration — the important part is that the condition becomes false once the incident is resolved, which is how the loop ends.
3. Delay. Set the delay to your update cadence (e.g., 2 hours). This is how long the ticket can stay quiet before a reminder fires.
4. Reset delay. In the delay step, enable reset on new activity and choose Message from a responder. Now every time someone on your team posts, the 2-hour timer restarts. The reminder only fires when responders have gone silent for the full period — so you never interrupt active work. Learn more about Reset Delay on New Activity.
5. Cancel on Status/Priority change. In the delay step, enable Cancel on Priority & Status field changes. If the ticket priority is reduced, or its solved - the automation is automatically cancelled (and stops nagging!). If the ticket priority is raised again - a new automation will be created.
Overlap protection: You can only use message-based reset events when your trigger is not "Message Added." Because we used "Ticket Updated," message resets are allowed. If you switch the trigger to "Ticket Message Added," ClearFeed will reject message-based resets to avoid infinite loops. See Reset Delay on New Activity.
6. Action — Send Message as a private comment. Add a Send Message action and configure it to post a private comment on the ticket (an internal note visible to your team, not the customer):
The reminder stays internal. The assignee then writes the actual update.
7. Make it recurring. Enable Re-enqueue automation on completion. After each reminder, the automation re-checks the condition and waits another cycle. As long as the incident stays critical and open, the reminder repeats on cadence. Learn more about Recurring Automations.
8. Additional Automation. You may need to add an identical automation on Ticket Creation as well if your incidents arrive critical from the first message.
When the loop stops
The recurring cycle ends automatically when:
Priority is lowered or Status leaves
Open(the condition no longer matches) — the normal, happy-path ending.The ticket is disabled or deleted.
An Invariant field change cancels it.
No manual cleanup needed — resolve the incident and the reminders stop.
Best practices
Tune the cadence to severity. 1–2 hours for critical, longer for lower severities. Match the delay to your stakeholders' tolerance for silence.
Reset on responder activity if the goal is "the team should speak up." Reset on non-responder (customer) messages only if you want any chatter to pause the reminder. You can enable both so any activity delays it.
Narrow the condition if you see redundant reminders. "Ticket Updated" can fire several times as an incident evolves; pinning the condition to a specific Status or a Custom Field (purpose built for tracking incidents) keeps the behavior focused where it matters.
Test on a non-critical channel first before enabling on production incident channels.
Pair with SLAs. Set a First Response target so both the first reply and ongoing updates are covered.
Last updated