Outcome
By the end of this lesson, you will be able to discover your own service in ZopNight, explain why a deployed service and a discovered resource are not the same object, and schedule the thing you just shipped.
| Tier | Operator |
| JTBD | ”Make the thing I deployed show up where I manage cost.” |
| Personas | Platform Engineer · SRE · FinOps Analyst |
| Prerequisites | M1.2, M1.3, M1.8.L2 |
| Time | 9 minutes |
| Bloom verb | Discover (Apply), Explain (Understand), Schedule (Apply) |
1. Concept
You now have two views of the same running thing, and they are genuinely different objects.
ZOPCLOUD SEES a Service, in an Environment, in a Project. Shaped by your deploy: image, port, replicas.
ZOPNIGHT SEES the cloud resources that service consumes: the compute it runs on, the load balancer in front of it, the volume under it.One is the thing you shipped. The other is what it costs. They are linked by the cloud account underneath, which is why M1.1 came first: without a connected account, ZopNight has nothing to discover.
Why this ordering matters
A deploy creates cloud resources. Discovery finds cloud resources. So the sequence is fixed:
deploy → cloud creates the resources → discovery runs → they appearIf your new service is not in ZopNight yet, the usual answer is that discovery has not run since you deployed, not that something is broken. M1.2.L5 covers the refresh trigger.
What is schedulable, and what is not
Not everything you deploy can be stopped on a clock. From the supported list, these are the shapes you are most likely to have just created:
SCHEDULABLE EC2 instances, Compute Engine VMs, Azure Virtual Machines, EKS/GKE/AKS node groups, RDS and Cloud SQL instances, ECS services, Cloud Run, Container Apps
NOT SCHEDULABLE the load balancer, the static IP, the registry, the storage bucket. They cost money but there is nothing to stop.A service whose only footprint is serverless has a smaller schedule story and a bigger rightsizing one. That is not a failure of the exercise, it is the answer.
2. Demo
START hello-api deployed, running, answering on its URLSTEP 1 discovery runsSTEP 2 ZopNight lists the compute behind hello-api-devSTEP 3 attach it to the nightly schedule, 19:00 stop, 08:00 startRESULT the URL stops answering at 19:00 and answers again at 08:00That last line is the whole course in one sentence: you deployed something, and now it costs money only while somebody could be using it.
3. Hands-on (6 min)
1. In ZopNight, find the resources created by your deploy. Filter by the account and the region you deployed into.2. If it is not there, trigger a discovery refresh and wait.3. Attach the compute to a schedule: stop at 19:00, start at 08:00, in your own timezone.4. Note which parts of your service are NOT schedulable, and why.5. Wait for the next firing, or set the schedule a few minutes out so you can watch it happen.6. Open the URL after the stop time. It should not answer.Do it through MCP. The same task you just did in the console, asked in one sentence.
BEFORE The service from L1 or L2 running, and a ZopNight account on the same cloud.ASK "Find the resources behind my hello-api deploy and put them on a 19:00 to 08:00 schedule."CHECK the schedule lists the compute, and not the load balancer. A schedule that claims to cover something unstoppable is the mistake this lesson is guarding against.Tools behind it: get_discovery_summary (read, Explore), list_resources (read, Explore), create_schedule (write, tier 2, reversible), attach_resource_to_schedule (write, tier 2, reversible). The full catalogue is at zop.dev/learn/mcp-tools.
4. Knowledge check
Q1
Your service is deployed and answering, but nothing about it appears in ZopNight. The first thing to check:
A. Whether write access is enabled
B. Whether discovery has run since you deployed
C. Whether the service is exposed
D. Whether the deploy is green
Show answer
Correct: B. Discovery finds cloud resources on its own schedule, and a deploy that finished five minutes ago may simply predate the last run. Write access governs what an assistant may change and has nothing to do with visibility. Exposure decides whether the internet can reach it, not whether ZopNight can see the compute.
Q2
Which of these, created by your deploy, cannot be put on a schedule?
A. The EC2 instance the service runs on
B. The load balancer in front of it
C. The RDS instance behind it
D. The node group under the cluster
Show answer
Correct: B. A load balancer has no stopped state to move it into. It still costs money hourly, which is why the answer to a load balancer’s cost is deletion or consolidation rather than scheduling. A, C and D all have a stopped state, which is what makes them schedulable.
Q3
Why does M1.1, connecting a cloud account, have to come before this lesson?
A. Because the deploy needs the credentials
B. Because discovery reads the cloud account, and without one there is nothing to find your resources with
C. Because scheduling is billed per account
D. Because the assistant authenticates through it
Show answer
Correct: B. ZopCloud deploys through its own path; the connected account is what gives ZopNight the read access it needs to see what that deploy created. This is the join between the two products, and it is the reason the capstone sits at the end of this course rather than the start.
5. Apply
The honest test of this lesson is the URL going quiet at 19:00. If it does not, one of three things is true: the schedule is not attached to the compute, the compute is not what serves the request, or the schedule has not fired yet.
KEEP the schedule name which resources it covers the first firing, from the history viewRelated lessons
- L4: Drive it through MCP
- T1.M1.2.L5: When discovery is stale
- T1.M1.3.L5: Attaching resources and groups
Glossary terms touched
Schedule · Deployment · Environment schedule · Resource group