how to handle "it worked yesterday" tickets

TL;DR

"It worked yesterday" means something changed, your job is to find what. Check deploys and config changes on your side first, then walk the user through what changed on theirs (browser updates, settings, data, permissions). Most of these tickets resolve to one of three causes: a recent release, a user-side environment change, or a data or permissions change. Say what changed and what you are doing about it, users accept regressions they understand.

The query

how to handle "it worked yesterday" tickets

Use this when

• A user reports a feature that broke overnight
• Multiple tickets arrive with the same "suddenly stopped working" phrasing
• You need a regression triage runbook for the team
• Agents guess instead of investigating on these tickets

Not for

• Scheduled downtime or maintenance windows
• New-feature onboarding confusion
• Proactive incident communication
• Performance degradation over time (different problem)

Steps

1. Take the report seriously, but verify the timeline

"When did you last see it working?" Pin down actual dates and times. "Yesterday" is often three weeks ago, which changes the search window.

Expected output: a concrete last-known-good timestamp in the ticket.

2. Check your side first: deploys, flags, config

Look at release notes, deploy logs, and feature-flag changes in the window between last-known-good and the report. This is the fastest path to the answer.

Expected output: either a suspect change (with deploy ID) or a confirmed "nothing shipped in that window."

3. Ask the user what changed on their side

Browser updates, OS updates, password changes, new team members, permission changes, different device. Ask conversationally, not as a checklist.

Expected output: a list of user-side changes in the same window, or an explicit "nothing changed" from the user.

4. Check data and permissions

Expired trials, changed plan limits, revoked API keys, deleted or archived records the feature depends on. Regressions caused by data are the sneakiest ones.

Expected output: account state, plan, and key permissions verified current.

5. Reproduce with the user's exact state

If you can reproduce it with their account, it is your bug. If you cannot reproduce it anywhere, it is their environment. Both are useful answers.

Expected output: a reproduction result tied to a specific account or environment.

6. Tell them what changed and what happens next

"We shipped a change on Tuesday that broke exports for files over 50MB. We are rolling it back now, you should be good within the hour." Transparency kills the frustration.

Expected output: the reply names the cause and the next action with a timeline.

Variant phrasings

"it used to work" support troubleshooting

Same playbook. The timeline question in step 1 matters even more here, because "used to" can mean anything.

how to troubleshoot a feature that suddenly stopped working

Same six steps, works for internal IT tickets too. The three cause buckets (your release, their environment, data or permissions) cover the vast majority.

regression triage checklist for support

Use steps 2 through 4 as your team's triage checklist before escalating. Escalations that arrive with "checked deploys, nothing shipped" get engineering attention faster.

Why it happens

These tickets are emotionally loaded because the user feels something was taken from them. The instinct is to argue ("are you sure it worked?") or to guess. Both make it worse. The delta-hunt approach works because software does not break spontaneously, it breaks from change, and change leaves a trail.

Edge cases

• Multiple users reporting at once: skip to step 2, it is almost certainly your side. Treat it as an incident, not a ticket.
• User insists nothing changed: believe them for now and dig into step 4, silent permission or plan changes are the usual culprit.
• Third-party dependency changed: check status pages and changelogs of integrations, then communicate it honestly ("our payment provider changed their API response on Tuesday").
• Actually a UX change: sometimes nothing broke, the UI just moved. Say so plainly and show them the new location, dont defend the redesign.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstcfH1lW-ev-kGJ-mOiorkA

Resolved from the public thread: https://vectle.com/posts/pstcfH1lW-ev-kGJ-mOiorkA

Thread query: how to handle "it worked yesterday" tickets

TL;DR: "It worked yesterday" means something changed, your job is to find what. Check deploys and config changes on your side first, then walk the user through what changed on theirs (browser updates, settings, data, permissions). Most of these tickets resolve to one of three causes: a recent release, a user-side environment change, or a data or permissions change. Say what changed and what you are doing about it, users accept regressions they understand.