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, ignores whatever schedule the resource is on, and always asks you to confirm first.

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 with:
   - Resource name and UID
   - Current state
   - Action being requested
   - Effect summary (e.g., "Will stop ~$24/day of billing")
5. Click Confirm
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, and it says exactly what is about to happen.

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. Confirmation modal lists the resources (truncated if many) + summary
6. Click Confirm
7. Worker pool processes the actions (4 parallel workers by default)
8. Bulk action status panel appears with per-resource progress
9. Each resource transitions to Stopped state as its action completes

Only four actions run at a time. Firing a hundred requests at a cloud provider at once gets you rate-limited, which is slower than going steadily. A hundred resources take 3 to 5 minutes.

Action status semantics

Every action has a lifecycle:

STATE             MEANING
─────────────────────────────────────────────────────────
queued            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)
timeout           The action took too long; awaiting verification

The Resources 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 not just a “are you sure?” prompt. It carries information:

┌─────────────────────────────────────────────────────────┐
│  Stop EC2 Instance                                       │
├─────────────────────────────────────────────────────────┤
│  Resource:    prod-web-1                                  │
│  UID:         i-0abc123def456                            │
│  Account:     prod-aws-us-east-1                         │
│  Current:     Running                                     │
│  Action:      Stop                                        │
│                                                          │
│  Effect:                                                  │
│  - Compute billing stops immediately                      │
│  - EBS volumes continue billing                           │
│  - Estimated savings while stopped: ~$24.30/day          │
│                                                          │
│  Note: This is a MANUAL action and bypasses any schedule │
│  attached to this resource. The schedule will resume on   │
│  its next firing.                                         │
│                                                          │
│       [Cancel]                          [Stop the VM]     │
└─────────────────────────────────────────────────────────┘

The modal is the last chance to catch a wrong click. It also teaches: the user reading the modal learns that EBS keeps billing, that schedules will resume, and what the action’s financial impact is.

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 requires the scoped-write permissions covered in M1.1 L2 (AWS) and L3 (GCP, Azure). If the IAM policy does not grant the start/stop actions:

• The Stop button is grayed out with a tooltip explaining the missing permission
• The Permission Visibility drawer shows the relevant action as Denied
• The customer’s path is to add the scoped-write extension to their IAM and refresh

The button never silently fails. If a click does nothing, the disabled tooltip explains why.

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 appears with effect summary
T+18 sec  Confirms
T+18 sec  Action queued
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 to Slack channel
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: note the effect summary.
5. Confirm.
6. Watch the action status progress: queued → 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 the sticky banner and the per-resource progress panel.

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 the bulk action with “Select All Filtered,” confirm once, let the worker pool process in parallel
C. Write a script
D. Schedule them off

Q3

The Stop button on a specific resource is grayed out with a tooltip “Missing permission ec2:StopInstances.” Most defensible response:

A. File a support ticket
B. Use the cloud provider’s own console instead, since ZopNight does not expose that specific control itself
C. Add the ec2:StopInstances permission to the cloud-side IAM policy (with whatever tag conditions are appropriate)
D. Wait

5. Apply

Manual start/stop lives in the Resources page:

• Resources page: single resource: click row → Stop / Start button
• Bulk selection: checkbox + sticky banner → Stop selected / Start selected
• Action status panel: appears at the bottom of the page during bulk actions

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

Glossary terms touched

Manual action · Bulk action · Confirmation modal · Worker pool · Action status