Manual start/stop with confirmation

Outcome

By the end of this lesson, you will be able to execute a manual start or stop on one or many resources and read the action status to confirm completion.

1. Concept

Anything that happens every week belongs on a schedule. Anything that happens once belongs here.

The team finishes early on a Friday and you stop the test cluster. A customer asks for a demo on a Tuesday evening and you start staging back up. Those are one-offs.

A manual action happens immediately and ignores whatever schedule the resource is on. A single start or stop asks you to confirm first; a bulk action from the selection banner does not.

The single-resource path

For one resource:

1. Open Resources, find the target
2. Click the resource row to open the detail panel
3. Click the Stop (or Start) button: large, primary action
4. Confirmation modal appears: "Are you sure you want to stop <name>?"
5. Click Stop (or Cancel)
6. Action status appears: Processing... → Completed (or Failed)
7. Resource state updates in the list within 60-90 seconds

That confirmation step is there on purpose. A stray click on Stop should not quietly take down something in production. The box is short: it names the resource and the action, and nothing else.

The bulk path

For many resources:

1. Open Resources, apply filters to narrow to the targets
2. Click the checkbox in the table header → "Select All Filtered"
3. The sticky selection banner appears with the count
4. Click "Stop selected" in the banner
5. No confirmation: one stop action is sent per selected resource, all at once
6. A toast reports the result: "Stopped N resources", plus a count of any that failed
7. Each resource transitions to Stopped state as its action completes

Because there is no confirmation on the bulk path, check the selection count in the banner before you click. Bulk actions here also ignore group ordering: if the resources belong to a group that starts and stops in sequence, act on the group instead (M1.4).

Action status semantics

Every action has a lifecycle:

STATE             MEANING
─────────────────────────────────────────────────────────
pending           The action is in the executor queue, not yet started
processing        The cloud provider API call is in flight
completed         The cloud provider confirmed success
failed            The action returned an error (with detail)
retry_exhausted   The action failed, was retried 3 times, and was given up on

The Inventory page shows where each action has got to. Click one still in progress and the panel opens with its full timeline, and the error in full if it failed.

Confirmation modal: what it shows

The confirmation modal is a plain “are you sure?” prompt:

┌─────────────────────────────────────────────────────────┐
│  Stop Resource                                           │
├─────────────────────────────────────────────────────────┤
│  Are you sure you want to stop prod-web-1?               │
│                                                          │
│       [Stop]                              [Cancel]       │
└─────────────────────────────────────────────────────────┘

The modal is the last chance to catch a wrong click. It does not spell out the effect, so know it yourself before you click: stopping an EC2 instance stops compute billing, its EBS volumes keep billing, and any schedule attached to the resource fires again on its next event.

What the action does NOT do

Manual stop does not detach the resource from its schedule. The schedule remains attached and fires on its next scheduled event. A manual stop is a one-off. The schedule carries on as before.

If the user wants to stop the resource AND remove it from its schedule, the action is two steps: stop, then detach from schedule.

Overrides vs. manual

Manual stop is a one-shot. An override (covered in M1.5) is a time-bounded action that explicitly suspends or forces the schedule for a defined window. Use:

• Manual stop if the goal is “stop it now, schedule will handle the rest.”
• Override if the goal is “stop it for the next 48 hours regardless of schedule.”

The two surfaces are different. Read M1.5 for the override flow.

Permission requirements

Manual start/stop needs two things: a ZopNight role that can update resources, and a cloud account connected at Read + Write (the write permissions covered in M1.1 L2 for AWS and L3 for GCP and Azure). When either is missing, the control is grayed out with a tooltip:

• No ZopNight permission: “You don’t have permission. Contact your admin.”
• Read-only account: “This account is read-only. Upgrade to Read + Write in Settings → Cloud Accounts to enable scheduling.”

If the account is Read + Write but a specific cloud action is still denied, the control stays enabled and the action fails at the cloud. The Permission Visibility drawer (M1.1 L4) shows what is Denied.

2. Demo

A typical manual stop workflow:

T+0       Engineer notices a non-prod EKS cluster is idle for the weekend
T+5 sec   Opens Resources, searches "staging-eks"
T+10 sec  Clicks the cluster row → detail panel
T+12 sec  Clicks Stop
T+13 sec  Confirmation modal: "Are you sure you want to stop staging-eks?"
T+18 sec  Clicks Stop
T+18 sec  Action pending
T+19 sec  Status: Processing
T+45 sec  Cloud provider confirms: cluster scaled to 0 nodes
T+45 sec  Status: Completed
T+50 sec  Resource state in list updates to Stopped
T+50 sec  Notification fires, if a channel is subscribed to manual
          actions
T+60 sec  Audit log entry written

Less than a minute from intent to confirmed action. The confirmation modal added one second of friction; the rest is real cloud API latency.

3. Hands-on (7 min)

Use a sandbox or non-prod resource. Do NOT do this exercise on production resources.

1. Open Resources. Find a non-prod, single-instance resource (a dev EC2,
   a staging RDS, an idle Compute Engine VM).
2. Read the detail panel before acting. Note current state, attached
   schedule (if any), tags.
3. Click Stop.
4. Read the confirmation modal carefully: check it names the resource you meant.
5. Confirm.
6. Watch the action status progress: pending → processing → completed.
7. Once completed, verify in the cloud console that the resource is actually stopped.
8. Click Start to restart it (if appropriate).

Estimated time: 5 minutes including waiting for the cloud API.

BULK EXERCISE (if you have a sandbox with multiple resources):
9. Filter to 3-5 non-prod resources you can safely stop.
10. Use the bulk-action selection and Stop selected.
11. Note that there is no confirmation, and read the result toast.

4. Knowledge check

Q1

A manual stop on a resource that has a schedule attached results in:

A. The schedule is deleted
B. The schedule is paused
C. An error, since a manual stop is not allowed on any scheduled resource at all in the product
D. The resource stops immediately; the schedule remains attached and will fire on its next scheduled event

Q2

A team needs to stop 47 staging resources before the weekend. Best approach:

A. Click the Stop button 47 separate times, once for each of the staging resources in the filtered list on the page too
B. Filter to the 47 resources, use “Select All Filtered,” then Stop selected in the banner
C. Write a script
D. Schedule them off

Q3

The start/stop control on a resource is grayed out with the tooltip “This account is read-only. Upgrade to Read + Write in Settings → Cloud Accounts to enable scheduling.” Most defensible response:

A. File a support ticket
B. Use the cloud provider’s own console instead, since ZopNight cannot act on it
C. Upgrade the account to Read + Write and grant the write permissions
D. Wait for the next discovery run

5. Apply

Manual start/stop lives in the Inventory page:

• Cloud Estate → Inventory: single resource: click row → Stop / Start button
• Bulk selection: checkbox + sticky banner → Stop selected / Start selected
• Bulk result toast: reports how many resources started or stopped, and how many failed

For ongoing scheduled start/stop, build a schedule in M1.3. For time-bounded overrides, use the Overrides feature in M1.5.

Related lessons

• L5: When discovery is stale (next)
• M1.3: Build your first schedule
• M1.5: Overrides