Every AI Screening Campaign Needs a Stop Button

Until June 2026, the only way to stop a running AI screening campaign at HireQwik was to find an engineer and ask them to kill the backend container. That was the actual recovery plan for a campaign launched against the wrong job description, the wrong candidate list, or a rubric nobody had checked before hitting send. Then DR-052 shipped a real stop control, live on both Drives and Resume Screening since June 8, 2026, and a recruiter can now stop the campaign from the same screen they were already looking at, with no engineer involved.

This matters more than it sounds like it should. A screening campaign is not a document you can quietly close and reopen later. Once it launches, invites go out, candidates start booking slots, and interviews start running. A campaign that was configured wrong does not sit still while someone figures out the fix. It keeps going, and every minute it runs, it costs more to unwind.

The two stop controls: “Stop drive” and “Stop screening”

HireQwik ships two separate stop controls, because Drives and Resume Screening are two different flows with different things running inside them. On the in-progress view for a Drive, there is a “Stop drive” button. On Resume Screening, there is a “Stop screening” button. Both do the same job for their own flow: they halt everything that has not already happened, and they leave everything that has already happened alone.

Neither button is buried in a settings menu. They sit on the screen a recruiter is already looking at while a campaign is running, because the moment you notice a problem is the moment you need to act on it, not five clicks later.

The pre-launch confirmation gate catches most mistakes first

The best stop button is the one you never need. Before a campaign fires at all, HireQwik shows a confirmation screen: the role, the candidate count, the slot schedule, and the credit cost. Nothing launches until a recruiter reviews that screen and confirms it.

This is the first line of defense, and it is deliberately placed before the stop control rather than instead of it. A recruiter scanning 3,000 rows on a Friday afternoon can still miss that a sheet pointed at the wrong job description, or that a slot schedule got copied from last quarter’s drive. The confirmation gate catches the mistakes that are visible in a summary. The stop button exists for the ones that only show up once the campaign is actually running.

A summary screen can only surface what’s wrong with the setup, not what’s wrong with the outcome. A candidate count can look right, the role can be right, and the slot schedule can be sensible, and a campaign can still be broken in a way that only shows up after the first few interviews come back with a rubric that doesn’t discriminate between candidates at all. That’s a different failure than a bad sheet, and it’s exactly the kind the stop control is for: something you only notice once the campaign is already talking to real candidates.

What stopping actually cancels, and what it leaves alone

Stopping a campaign is not a kill switch for everything with that campaign’s name on it. It is specific about what it touches. Interviews still marked scheduled or waiting are cancelled. Interviews already in progress, and interviews already completed, are left exactly as they are.

That distinction is the whole design. A recruiter who realizes midway through the day that a campaign was set up wrong does not want to erase the interviews that already happened correctly that morning. They want the campaign to stop moving forward from that point on, without touching what already ran.

Link revocation is the part that actually matters

Cancelling a database row is the easy half of stopping a campaign. The hard half is that an invite email already sat in a candidate’s inbox with a live join link in it, and that link does not know the campaign was stopped.

This is why stopping a HireQwik campaign also revokes the join links for every meeting still marked as not yet joined. A candidate who clicks afterward is told plainly that the recruiter called the interview off, rather than being dropped into a working meeting room. Before this existed, a sent invite stayed live for hours no matter what a recruiter did on the dashboard, and fixing the record and fixing what a candidate actually experiences turned out to be two separate problems. Only revoking the join itself solves the second one.

Solving that half properly needed its own writeup, since it involves a whole separate set of decisions: what the candidate sees, how long the exposure used to last, and what happens to credits for people who never got that far. We cover that in detail here. This post stops at the mechanic that makes the revocation possible in the first place.

Credits refund automatically, not on request

The other thing a stopped campaign has to settle is money. Every candidate slot in a campaign has a credit tied to it, and a campaign that gets stopped halfway through has unused credits sitting against candidates who never joined a call.

HireQwik refunds those credits to the original payer automatically, counted per candidate whose interview never started. The refund runs as one atomic operation, meaning a single database update claims the cancellation, so a recruiter clicking stop twice, or a retried request, cannot accidentally issue the refund a second time. Nobody has to file a support ticket to get unused credits back. Stopping the campaign and getting the refund are the same action.

That atomic step matters more than it sounds like it should. A recruiter under pressure, watching a campaign go sideways, is exactly the kind of person who clicks a button twice to make sure it registered. A refund process that isn’t built to handle a double click either has to add friction back in, a confirmation dialog, a loading spinner that locks the button, or it risks paying out twice for the same cancelled candidates. Tying the refund to the same database claim that cancels the interviews sidesteps the problem instead of guarding against it after the fact.

Before DR-052, the only stop button was killing the container

It’s worth being honest about what this replaced, because it was not a graceful fallback. Before June 2026, halting a wrongly-configured campaign meant finding an engineer and asking them to kill the backend container it was running in. That works, in the sense that it stops the process. It also has no concept of “cancel the scheduled meetings but leave the completed ones alone,” no link revocation, and no refund logic. It is a blunt instrument built for an emergency, not a control a recruiter should ever need to reach for.

The ability to interrupt an automated system mid-run, rather than just switch it off entirely, is showing up as a stated requirement in AI governance more broadly. The EU AI Act’s human oversight provisions call for high-risk AI systems to be built so a human can intervene in or halt their operation (EU AI Act, Regulation (EU) 2024/1689), and the US NIST AI Risk Management Framework lists the ability to disengage or deactivate an AI system as part of managing it responsibly. Neither document is about hiring specifically, but the underlying idea is the same one behind a “Stop drive” button: a system that runs unattended still needs a way for a person to step in.

Engineering teams describe this same idea with a different vocabulary: a kill switch or an emergency brake, the kind of control that exists specifically so an operator never has to escalate to someone else just to make a runaway process stop. Aviation and industrial-safety fields formalized this decades before software did, under the general heading of a human-in-the-loop override, precisely because a system running exactly as designed can still be doing the wrong thing in a specific situation nobody anticipated when it was built. A hiring pipeline sending interview invites at scale is a smaller stage than a factory floor or a cockpit, but the underlying discipline transfers directly: build the override before you need it, not after the first incident makes the gap obvious.

When a stop button actually gets used

In practice, the moment a recruiter reaches for the stop control is rarely dramatic. It’s a sheet that got connected to the wrong job description trigger, so invites start going to a candidate list meant for a different role. It’s a drive that got launched twice because two people on the team both thought it hadn’t started yet. It’s a slot schedule copied from a previous campaign that nobody updated before this one went live.

None of these are exotic failures. They are the kind of ordinary mistake that happens whenever a human configures something and a system executes it exactly as configured, mistakes included. What changed with DR-052 is not that mistakes stopped happening. It’s that catching one no longer means paging an engineer and hoping the container shuts down cleanly.

There’s a limit worth naming here too. Stopping a campaign does not undo the interviews that already completed before someone noticed the problem. If a campaign should never have gone out at all, wrong role, wrong candidate pool, whatever the reason, the candidates who already finished a screening conversation still have a result sitting in the system. The stop button protects everyone downstream of the moment you click it. It doesn’t reach backward. A recruiter cleaning up after a bad launch still has to look at what already ran and decide by hand whether those results count for anything.

What to check after you stop a campaign

Clicking stop is not the last step. A recruiter who just halted a wrongly configured run still has cleanup to do, and skipping it is how a fixed mistake turns into a second one a week later.

Start with the shortlist. Every interview that finished before the stop landed still has a real verdict sitting in the system, scored against whatever the campaign was actually configured to test. If the underlying job description was wrong, those verdicts are not automatically wrong too. They were scored against the wrong target, and a recruiter has to look at each one and decide by hand whether it transfers to the corrected relaunch or gets thrown out entirely.

Next, check the refund actually landed against the right budget line before assuming it did. The atomic refund described above is reliable, but reliable does not mean invisible, and a TA lead planning next quarter’s spend should confirm the credits are back where they’re expected rather than trusting the mechanism blind. This takes a couple of minutes against the billing view and saves a confused finance conversation weeks later when the quarterly numbers don’t reconcile and nobody remembers a run got pulled midway through.

Finally, if the mistake was a wrong candidate list rather than a wrong job description, the corrected relaunch needs a genuinely different spreadsheet, not the same file with the error patched over. A halted run and its relaunch sharing overlapping rows is one of the more common ways a second copy slips through days after everyone assumed the mess was resolved. Cross-checking the new upload against the old one, row by row if the roster is small enough, catches this before a fresh round goes out to people who were already contacted once. This kind of manual reconciliation is tedious and unglamorous, but it takes minutes, and skipping it is how a well-intentioned correction turns into an awkward apology for a second email nobody asked for.

Where this fits in the rest of campaign control

Stopping a campaign is one piece of a broader shift toward giving recruiters real control over a screening run once it’s live, not just at setup. The same instinct shows up in how HireQwik handles what actually counts as a full interview slot as a drive fills up, and in how a scoring rubric that quietly collapses every candidate to the same handful of scores gets caught and corrected rather than shipped as-is. It’s a different defect from the one where scores compress into a narrow middle band instead of spreading out, but the response is the same: catch it and fix it, don’t let it quietly run a whole drive. All three are the same underlying principle: an automated screening system should be legible and interruptible while it is running, not just configurable before it starts.

It’s also worth separating this from a related question we’ve answered elsewhere: how many interviews the platform can actually run at the same time. That’s about capacity while a campaign is healthy. This is about what happens when a campaign shouldn’t be running at all.

If you’re setting up your first campaign, or auditing how a live one is configured, the HR dashboard is where both the confirmation gate and the stop controls actually live. Worth checking before your next drive launches, not after.