Break It First

Kits

Support-ticket script rescue

How we repair a script that runs without errors but gets rows wrong.

Covers: one script of yours that runs but gets rows wrong, tested and repaired after a written brief.

This is our own deliberately flawed, AI-style demo script, run on a made-up ticket file. It shows what a test run on your own script looks at.

Limit: Mock API, made-up data, no real key.

What you get

  • Your own script, tested and repaired the same way, after a written brief.
  • Its test report: what we broke, what caught it and what got through.
  • A plain list of its limits, and a report or log after every run, so you can check the counts the next day.

What we need from you

  • A sample export, or access to a test copy of the tools it connects.
  • A written brief: what it should do and where you think it breaks.

Price: from $49, fixed quote in writing before any work.

Timing: the written quote states the delivery date.

Ask about this kit

or write to [email protected]

The problem

A script can run with no error, print 'Processed 9 tickets', and still get rows wrong. Ours did: only 5 of the 9 valid tickets were right.

What we broke (and fixed)

  • Before: 5 of 9 valid tickets right. After: 9 of 9, and the one unreadable row is listed with its reason.
  • Before: 2 rows lost with no trace, a US-format date and a bad date. After: 0 lost. The bad one is in a rejects file with its reason.
  • Before: the API key in 9 log lines. After: 0.
  • We made the service flaky and slow. The fixed script retries, and gives up on the slow one after 3 attempts of 0.3 s.
  • The fix has a cost, and we show it: 13 API calls instead of 9, and 1.26 s instead of 1.03 s.

Before / after runSupport-ticket script rescue

Short video, no sound. The slides below show the same steps.
  1. Hook: the old script printed "Processed 9 tickets, 2 breached". It ran fine, but only 5 of 9 tickets were right.
  2. Terminal output, before: 9 rows, 5 of 9 right, 9 API calls, 1.03 seconds. After: 9 of 9 right, 13 API calls, 1.26 seconds.
  3. Before: ticket T-1005 appears twice, once typed as t-1005 with spaces, both with SLA 24 hours. After: one row, closed, SLA 4 hours.
  4. Five defects, among them a hard-coded key: it was printed in 9 log lines before the fix and in 0 after.
  5. After the fix, a failed lookup gets a note and an unreadable date goes to a rejects list with its reason. Before, 2 rows vanished.
  6. Result: 18 tests pass. A mutation check catches 19 of 20 deliberate breakages. The survivor is the 403 answer, which no test reaches.

What it does after the fix

Every valid ticket comes out right, and every unreadable one is listed with its reason. The key stays out of the logs, and retries stop at a set limit.

Limits

  • Mock API, made-up data, no real key.
  • 1 of 20 planted bugs got through. The script treats a 403 answer like any other error. Our mock service never sends a 403, so no test reaches that line.
  • Our own demo kit, run on made-up data.

What happens after you write

  1. You write

    Email us or send a DM on X: what it does and where you think it breaks.

  2. We ask a few questions

    About your tools, your data and what counts as done.

  3. Fixed written quote

    The quote states the price and the delivery date.

  4. Work starts only after you say yes

    Nothing is built before you agree to the quote.

Want this on your data?

Ask about this kitSend a DM on X

or write to [email protected]

Have a script like this? Ask about a test run.

Kits set up on your data from $49. A test run on your own automation from $45. Fixed quote in writing before any work.

This kit's logged test run

tests
18 passed -> OK
bugs
19 of 20 planted, caught
data
made-up, mock services
Our own demo kit, run on made-up data.