Skip to main content

Managing your snipes (Recent Snipes)

When a sniper rule or a Direct Snipe successfully reserves a server, CloudCO writes a row to your Snipes history. You can view and act on those rows from the dashboard:

https://cloudco.me/dashboard/sniper/snipes → Recent Snipes table.

Each row carries the Server ID (the provider's identifier), the Provider, the rule that produced it (or Direct Snipe for one-off purchases), the Price, and the date. Two actions are available per row:

  • TERMINATE — asks CloudCO to destroy the server on the provider.
  • REMOVE — clears the row from your CloudCO history. Does not touch the provider.

The rest of this page explains exactly what each action does, when to use it, and what to expect per provider.

There is also a separate, account-wide red button — STOP SNIPE — in the sidebar. It is the emergency "pause everything" button and is documented below.

STOP SNIPE / START SNIPE (emergency pause-all & one-click resume)​

In the dashboard sidebar (visible on every page) there is a single large coloured button that toggles between two states:

  • STOP SNIPE (red, ◯ icon) — shown when at least one sniper rule is active. Pauses every active rule in one click.
  • START SNIPE (green, ▶ icon) — shown when one or more rules are currently paused by a previous STOP SNIPE press. Resumes those rules in one click.

This is the dashboard equivalent of the operator-side tools/emergency_pause_user_rules.py script — it gives you a reversible kill switch for your account's sniping activity without ever touching your existing servers.

STOP SNIPE — what it does​

  • Finds every sniper rule in your account where status is ACTIVE.
  • Sets each one to PAUSED.
  • Marks each paused rule so the button can later identify and resume exactly these rules with START SNIPE.

The background sniper loop only fires on ACTIVE rules, so the moment the change is saved, no more snipes will fire under your account.

STOP SNIPE — what it does NOT do​

STOP SNIPE never touches anything other than your own active rules. Specifically:

  • It does NOT terminate any servers. Anything you already own at Vultr, Hetzner, OVH or DigitalOcean keeps running. Billing on the provider side is unaffected.
  • It does NOT delete history. Your Recent Snipes table stays exactly as it was.
  • It does NOT touch completed or failed rules. Only ACTIVE rules are paused. PAUSED, COMPLETED and FAILED rules are left alone.
  • It does NOT affect rules you paused manually. Rules you'd paused via the per-rule Pause button on the Snipes page are explicitly not candidates for STOP SNIPE (they're already paused) and, more importantly, are not candidates for START SNIPE either — see below.
  • It does NOT affect other users. Even if you and a teammate share an organisation, STOP SNIPE only pauses your rules.

START SNIPE — what it does​

After you've pressed STOP SNIPE, the same button flips to a green START SNIPE. Clicking it resumes only the rules STOP SNIPE paused — every rule that's still in the "paused by the kill switch" state.

  • Rules you'd paused manually (per-rule Pause button on the Snipes page) stay paused. START SNIPE never resurrects those, because pausing them was a deliberate choice you made for that specific rule.
  • Rules that completed (already bought a server) or failed are never resumed by START SNIPE — those are terminal states by design.
  • Already-active rules created or resumed since the last STOP SNIPE press are untouched (they're already running).

In short: STOP SNIPE → START SNIPE is a clean round-trip for whatever you put to sleep with that one press, and it never disturbs rules whose state you set manually.

What happens if I touch rules manually after STOP SNIPE?​

The button keeps track of "kill-switched" rules with a flag on each rule. Anything you do to that rule afterwards clears the flag:

  • Manually resume the rule from the Snipes page → flag cleared (the rule is active again; nothing for START SNIPE to do).
  • Manually pause the rule again → flag cleared (you've made an explicit choice for this rule; START SNIPE will leave it alone).
  • The rule fires and completes or fails → flag is irrelevant (terminal states are never resumed by START SNIPE).

So you can freely mix STOP SNIPE / START SNIPE with per-rule actions on the Snipes page — they don't interfere with each other.

When to use STOP SNIPE​

Typical scenarios:

  • You notice unexpected snipes happening (wrong rule, wrong budget, etc.) and want to halt them while you investigate.
  • You're about to make significant changes to your account (rotating provider credentials, changing billing, etc.) and want sniping idle in the meantime.
  • You want to make sure no rule fires while you're away (e.g. travelling, on call) without deleting your carefully tuned setup.

If you also need to destroy already-acquired servers, do that separately from the Recent Snipes table (see TERMINATE below) or from the provider's own dashboard.

Confirmation flow​

Both buttons open a confirmation modal that tells you exactly how many rules will be affected, broken down by provider — e.g. "Pause 3 active sniper rules across: Vultr (2), Hetzner (1)." or "Resume 3 sniper rules that STOP SNIPE paused, across: Vultr (2), Hetzner (1)." You must confirm before anything changes. If there's nothing to do (zero active rules, or zero kill-switched rules), the button tells you so and changes nothing.

If you need help from CloudCO operations​

If you ever find yourself in a situation where STOP SNIPE isn't enough (e.g. you've lost dashboard access, or you want sniping disabled at the platform layer regardless of any code path), email [email protected] with the subject "Emergency: pause sniping" and we can flip a platform-wide circuit breaker on the operations side within minutes.

TERMINATE​

Clicking TERMINATE sends a delete request to the relevant provider for the server in that snipe row. The action is irreversible: the provider destroys the server and wipes its data.

Outcome statuses​

CloudCO reports one of the following back to you:

StatusMeaningWhat to do
TerminatedThe provider confirmed the server has been destroyed.Nothing — billing stops on the provider's side as per their terms.
Already TerminatedThe provider reports this server no longer exists. Usually because you (or a teammate) deleted it on the provider's own dashboard earlier, or because a previous Terminate already succeeded.Click REMOVE to clear the history row from CloudCO.
Termination RequestedOVH only. The termination flow has started; OVH has emailed your account owner a confirmation token. The server is not yet destroyed.Open the email from OVH and click the confirmation link (or run POST /dedicated/server/{name}/confirmTermination with the token via OVH's API).
Manual Action RequiredCloudCO doesn't yet have the identifier it needs to issue a clean cancellation (most commonly: the order is still being provisioned, see below).Wait until provisioning completes and retry, or terminate the server in the provider's own dashboard and then REMOVE the row.

If the request fails outright (credentials revoked, provider outage, etc.), CloudCO surfaces the actual error message returned by the provider so you can diagnose it.

Per-provider behaviour​

Each provider exposes a different delete API, with different idempotency guarantees and different identifier requirements. CloudCO normalises the surface, but the underlying nuances are worth knowing.

Vultr​

  • Cloud-compute snipes (vc2-*, vhf-*, vhp-*, voc-*, vcg-* plans) → DELETE /v2/instances/{id}
  • Bare-metal snipes (vbm-* plans) → DELETE /v2/bare-metals/{id}
  • 404 from Vultr (instance unknown) is treated as Already Terminated.

Vultr terminations are immediate. Billing stops on the provider side as per Vultr's standard policy.

DigitalOcean​

  • DELETE /v2/droplets/{id} against your DigitalOcean account.
  • 404 from DigitalOcean (droplet not found) is treated as Already Terminated.

Hetzner Robot​

Hetzner's termination flow needs the server number (an integer assigned by Hetzner after provisioning is complete), not the auction transaction ID that we receive at order time. CloudCO automatically looks up the server number from the transaction:

  1. CloudCO calls GET /order/server_market/transaction/{id} to read the order status.
  2. If the transaction carries a server_number, CloudCO issues POST /server/{n}/cancellation with type=immediate.
  3. If it doesn't yet (auction orders typically need a few minutes — sometimes up to an hour — to provision), CloudCO returns Manual Action Required with a pointer to the Hetzner Robot console. Retry TERMINATE once your server appears there.

Hetzner immediate cancellations are billed pro-rata; see Hetzner's cancellation policy for refund details.

OVH (EU and CA)​

OVH dedicated-server termination is a two-step flow by design — this is OVH's safeguard against accidental termination of expensive long-lived resources:

  1. CloudCO calls POST /dedicated/server/{serviceName}/terminate. OVH emails your account owner a confirmation token. CloudCO reports back Termination Requested.
  2. You must click the link in that email (or call POST /dedicated/server/{serviceName}/confirmTermination with the token) to actually destroy the server.

CloudCO does not auto-confirm — only you, by clicking the email link, can complete the termination.

CloudCO resolves the OVH serviceName from the stored order ID by walking GET /me/order/{orderId}/details. If the order is still pending provisioning, you'll get Manual Action Required; retry TERMINATE once the server appears under Bare Metal Cloud → Dedicated Servers in the OVH Manager.

REMOVE​

Clicking REMOVE deletes the row from your CloudCO Recent Snipes list. That's it — the provider is never contacted, the server (if any still exists) is not affected.

Use REMOVE when:

  • You've already destroyed the server from the provider's own dashboard and want the entry gone from CloudCO.
  • A TERMINATE reported Already Terminated — the cleanup is purely cosmetic at this point.
  • The snipe failed mid-flight and you don't want the leftover entry sticking around (rare).

REMOVE is idempotent and per-user: removing a snipe only affects your own view; it doesn't impact billing, rules, or any other user.

Common scenarios​

"I deleted the server on the provider and now Terminate fails / shows a confusing message"​

Expected. CloudCO sees the provider responding "not found" for that ID. Click REMOVE to clear the row.

"I want the server gone right now"​

For Vultr and DigitalOcean, clicking TERMINATE destroys the server immediately.

For Hetzner, TERMINATE triggers an immediate cancellation if the server is provisioned. If you get Manual Action Required, the server isn't fully provisioned yet — wait a few minutes and try again, or cancel via the Hetzner Robot console.

For OVH, expect the email-confirmation step. The server is not destroyed until you click the link in the OVH email. This is OVH policy, not a CloudCO limitation.

"Terminate says Manual Action Required even after waiting an hour"​

The order may have failed at the provider side without CloudCO seeing it (rare but possible). Check the provider's own dashboard:

If the server isn't there, the original snipe didn't actually provision anything billable. Click REMOVE to clear the entry.

"Terminate returns an error mentioning credentials"​

Your stored provider credentials may have been revoked or rotated. Re-save them in Settings → Providers and retry. CloudCO never holds onto your account budget — every termination call uses your own API token.

Safety notes​

  • TERMINATE is irreversible. Once a provider accepts the delete request (or, for OVH, once you confirm the email), the server's storage is destroyed. CloudCO surfaces a confirmation dialog before sending the request — read it carefully.
  • REMOVE only changes your CloudCO view. It cannot leak data, cannot affect billing, and cannot impact other users in your organization. If you click REMOVE on a row whose server is still running on the provider, the server keeps running and you keep being billed by the provider until you terminate it directly.
  • Other users in your organisation cannot act on your snipes. Each row is owned by the user who triggered the snipe; the API filters strictly by user_id.