Skip to content
Greenlight by Shift AI

Kill switch & restore

Admin guide

The kill switch is the single most powerful day-to-day lever Greenlight gives IT. It stops a running app immediately by scaling its pod to zero and revoking the app’s workload access keys. The app’s data, secrets, repo, and audit history are preserved so restore is possible.

When to use it

Use kill when you need to stop the app now and worry about the cause later. Common triggers:

  • The app is misbehaving — runaway loop, error spike, suspicious traffic.
  • An integration credential has leaked through the app and rotation isn’t enough.
  • A compliance or legal hold requires the app to stop until reviewed.
  • The app is being decommissioned and you want to verify nothing depends on it before permanent retirement.

Suspend is the resulting app state. Use the kill switch for immediate incident response; use normal suspension for planned maintenance or cost control.

Kill an app

  1. Open the app’s detail page. The Kill switch button is at the top right of the page, styled destructively.
  2. Type a reason. The dashboard requires a reason that lands in the audit log. Be specific — “investigating suspicious egress” is more useful in three months than “killed”.
  3. Confirm. The pod is scaled to zero and the workload proxy key is revoked. The app moves to suspended. Target time: under 30 seconds.

The audit event captures the actor, the app, the reason, and the previous app state. The kill cannot be undone silently — restore is its own audited action.

Restore an app

A suspended app stays in the dashboard with its data, secrets, and history intact. To bring it back:

  1. Open the suspended app’s detail page. The Restore button replaces the kill button.
  2. Type a reason. Same requirement as kill — the audit log captures why.
  3. Confirm. Greenlight restores the workload access key and scales the app back up. The app moves back toward active after health checks pass.

The restored app picks up from where it was. Database data is unchanged. Secrets are unchanged. The app’s URL is the same. End users don’t notice the restoration except that the app starts responding again.

Decommission

Decommission is the permanent retirement path. It is available only after the app is suspended and IT confirms the action.

When decommission runs, Greenlight deletes the app namespace, DNS record, and container images, archives the GitHub repo, and retains the logical database for the configured recovery window. The decommission event is written to the audit log.

Suspend (the softer option)

Suspend scales the app to zero pods and revokes the app’s workload proxy key. The app stops serving traffic but can be restored without deleting the app’s data or repo.

Use planned suspension for maintenance or cost control. Use the kill switch when you need immediate incident response.

What the audit log captures

For every kill, restore, suspend, resume, or decommission event:

  • The actor user id, role, and session.
  • The target app id, name, and previous state.
  • The reason text the actor entered.
  • The timestamp at the control plane.

Greenlight writes these events to the audit log. Full audit search and export are coming soon.

Next

App deployment & isolation The Kubernetes objects affected by kill and restore.
Audit & monitoring Where kill events surface for review.
Governance & policy Who has the kill role and how it's audited.