Use cases / When production breaks
Checkout is fixed. Which customers did we hit?
The outage is fixed, but support does not know exactly whom to email and finance does not know who may need a credit.
Jigward counts affected accounts rather than failed requests, separates who came back from who never did, spot-checks each group against raw events and puts the list in a team Application. Emails and credits stay with support and finance.
The film
Chapters
Read the narration
0:00 Checkout is fixed. Who do we email?
Checkout failed overnight. It's fixed now, but nobody can say which customers were hit, and support has to email them today. I'm Jigward. I turn the request into one task for support and finance, and I spell out what I won't do. Nothing starts until Jordan clicks Create. An admin connected the production logs read-only, and that's all the access this needs.
0:31 Count customers, not failed requests
I'll start in the logs, with one failed request from the incident. It shows which fields name the customer and the order. Customers retry, so counting failures would inflate the number. I count accounts instead, and scan only the incident window to limit cost.
0:51 Who came back, checked against raw events
Next, who came back? Most finished a purchase after the fix. The rest never did, and support contacts them first. Before anyone emails a customer, I read the raw events for one account from each group. Both match the queries, so the list is safe to work from.
1:13 One list for support and finance
A result file isn't something Jordan's team can work through. So I build them a small app holding every account. Customers who never completed are at the top. Support marks who they've contacted, and credits wait for finance.
1:32 The answer, and what stays with the team
I report the count, how I checked it, and what I didn't, like whether anyone was charged anyway. Emails and credits stay with the team.
What changes
Today. After the fix, an engineer writes log queries by hand the next morning, exports a file and someone reconciles it in a spreadsheet, or the impact is estimated from the error rate. Dashboards show an error rate, not who was hit, and the postmortem's "customers affected" field often stays blank. Counting failed requests overstates the impact, because customers retry. An estimate gives support nobody to email and finance nothing to decide on, account by account.
-
Before: An error rate, or a count of failed requests inflated by retries.
With Jigward: 214 accounts behind 389 failed checkouts, one row per customer.
-
Before: Emailing everyone who might have been hit, or a guess.
With Jigward: The 37 who never finished a purchase listed first, apart from the 177 who came back after the fix.
-
Before: A one-off file nobody can work through.
With Jigward: A team Application where support marks who was contacted and finance records each credit decision.
What Jigward does
Checkout is fixed, but which accounts do we email about last night's outage? I need a list my team can mark off.
Connected beforehand
- The support lead's Slack account is linked, so their direct messages reach Jigward.
- An AWS account is connected, so Jigward can read the production log groups an admin allowed. It is the only access the work uses.
-
Learns what names a customer
One failed request from the incident, read in the checkout worker's logs, shows which fields carry the account and the order.
-
Counts accounts, not failures
Customers retry, so Jigward groups the failures by account. One Logs Insights query, limited to the incident window, finds 214 accounts behind 389 failed checkouts.
-
Separates who came back
A second query keeps each account's latest checkout. Of the 214, 177 finished a purchase after the fix and 37 never did.
-
Checks against raw events
Before anyone is emailed, it reads the raw events for one account from each group. Both match what the queries said.
-
Builds the list support works from
It builds a team Application, "Affected accounts", with every account, the never-finished ones first, a contacted flag for support and a credit field that stays pending for finance.
-
Answers in the conversation
The summary comes back in the same direct message, with the count, how it was checked, what was not, and links to the Application and the Task.
Jigward in this case
-
Slack
The request arrives as a direct message to Jigward. Nothing starts until the support lead clicks Create on the Task card, and the summary comes back there.
-
Tasks
The Task keeps the log searches, both queries and the two spot checks.
-
AWS CloudWatch Logs
Log searches read one failed request and the raw events of two accounts, and two Logs Insights queries over the incident window count and split the accounts.
-
Applications
A team Application holds the 214 accounts, with a contacted flag and a credit field, on a page support and finance both open.
What comes back, and what stays with the team
What comes back
- The "Affected accounts" Application All 214 accounts, the 37 that never finished first, each with a contacted flag support sets and a credit field that stays pending until finance decides.
- The direct message in Slack The count, how it was checked, what was not, and what Jigward did not do, with links to the incident, the Application and the Task.
What the team decides
- Whom to email, and in what order.
- Who gets a credit and how much, and what goes in the postmortem. Jigward emails no customer and issues no credit.
What Jigward did not check
- Whether anyone was charged even though checkout failed.
- Contact details. The logs hold account IDs, so support looks contacts up in its own tools.
- Plan tiers and credit terms.
- Log groups other than the checkout worker's.
Meet your next engineering coworker
Bring a question
from your own project.
See how Jigward can help your team understand the system and move the next task forward.
Jigward is in closed testing. Accounts are created by hand; sending a request does not create one.