The event log · ZopDev University

Outcome

By the end of this lesson, you will be able to read a policy’s event log, trace who changed a policy and whether each apply or remove succeeded, and go to the cloud’s own scaling history to explain why a group scaled.


Prerequisites	M2.4.L1 - L5
Time	9 minutes

1. Concept

Every policy keeps an event log of its lifecycle: each time someone created, edited, applied, paused, resumed, removed or deleted it, and each result the executor reported back.

It answers two questions well:

WHAT THE EVENT LOG ANSWERS
  Who changed this policy, and when?
  Did each apply or remove reach the cloud, and if not, why not?

WHAT IT DOES NOT ANSWER
  Why did the group scale out at 03:00?
  How many instances were running at 14:00?
  Did this scaling cost us money?

The second set lives in the cloud, not in ZopNight. ZopNight writes the scaling rules at Apply; after that the cloud’s own autoscaler makes every scale-out and scale-in decision, and ZopNight does not ingest that activity.

The actions

The log records eight actions, and nothing else:

ACTION          WRITTEN WHEN                        STATUS
────────────────────────────────────────────────────────────────────
create          Policy saved (not yet applied)      completed
update          Policy edited, including a          completed
                rename or a mode change
delete          Policy deleted                      completed
apply           Apply queued for the executor       queued
remove          Remove queued for the executor      queued
pause           Status set to paused (database      completed
                only, no cloud call)
resume          Status set back to active           completed
                (database only, no cloud call)
status_update   The executor's callback after an    completed or
                apply or remove ran in the cloud    failed

Apply and remove are two-step. The apply or remove row only says the request was queued. The outcome arrives later as a status_update row with completed or failed. The callback does not repeat the action name, so read it together with the queued row just before it.

The fields on each row

FIELD             WHAT IT HOLDS
────────────────────────────────────────────────────────────────────
action            One of the eight actions above
status            queued, completed or failed
actor             Email of the user who did it; empty on a
                  status_update (the executor, no human in the loop)
errorMessage      The cloud or executor error, on a failed callback
previousConfig    On a status_update: the cloud config captured
                  before ZopNight wrote its own, used by Remove
                  to restore it
startedAt         When the action started
completedAt       When it finished (empty on a queued row)
createdAt         When the row was written

Rows come back newest first, 20 per page by default and up to 100.

Where to read it

The events are served by the policy’s events endpoint, GET /orgs/{orgID}/autoscaler-policies/{policyID}/events, and by the get_autoscaler_events MCP tool (one of more than 300 tools). Ask an agent “show me the events for the checkout-asg policy” and it calls that tool.

The console has no event-log view of its own, but two places cover most of what it holds:

Automate → Auto Scaling, policy card
  Status badge (draft, applying, completed, failed, paused...)
  and, on a failed policy, the latest error message and a
  Retry apply button

Activity → Audit Logs, Resource filter "Autoscaler Policy"
  Every create, edit, apply, pause, resume, remove and delete
  request, with the user and the source (console, API or MCP)

A worked log

EVENT LOG: checkout-asg (newest first)
────────────────────────────────────────────────────────────────────
CREATED AT          ACTION         STATUS     ACTOR / DETAIL
────────────────────────────────────────────────────────────────────
2026-09-19 09:31    status_update  completed  (executor)
2026-09-19 09:30    apply          queued     ops-lead@
2026-09-19 09:30    update         completed  ops-lead@
2026-09-15 08:00    resume         completed  ops-lead@
2026-09-12 17:30    pause          completed  ops-lead@
2026-09-08 14:06    status_update  failed     (executor) AccessDenied
                                              on PutScalingPolicy
2026-09-08 14:05    apply          queued     jane@
2026-09-08 13:55    create         completed  jane@

Read bottom up: Jane created the policy, her first apply failed on a missing IAM permission, ops-lead paused and resumed it (no cloud effect either time), then edited it, and the re-apply succeeded.

Why did the group scale? Go to the cloud

When the question is about scaling behaviour itself, open the provider’s own history and line it up with the policy’s last successful apply:

PROVIDER   WHERE THE SCALING HISTORY LIVES
────────────────────────────────────────────────────────────────────
AWS ASG    The Auto Scaling group's Activity tab (activity history),
           plus the CloudWatch alarm history for the policy's alarms
AWS ECS    Application Auto Scaling scaling activities for the
           service, plus the CloudWatch alarm history
Azure      The autoscale setting's run history in Azure Monitor,
VMSS       and the Activity log for the scale set
GCP MIG    The autoscaler's logs in Cloud Logging, and the MIG's
           status and recommended size in the console

The event log tells you which rules were live at that moment: the last status_update completed after an apply, with no later completed remove. The cloud history tells you which rule fired and why.

Patterns in the event log

PATTERN                                   WHAT TO DO
────────────────────────────────────────────────────────────────────
apply queued, no status_update after it   Executor has not reported
                                          back; check the policy card
                                          status before retrying
status_update failed, AccessDenied or     Fix the cloud account's
  similar                                 permissions, then Retry apply
Many updates with no apply after them     Edits that only renamed or
                                          changed mode; nothing changed
                                          in the cloud
pause with no remove, but scaling         Expected: Pause never touches
  continues                               the cloud. Remove to stop it
Frequent apply and remove churn           Edit and re-apply instead of
                                          rebuilding the policy

2. Demo

An on-call engineer is asked two questions about checkout-asg on Tuesday morning.

QUESTION 1: "Who changed the scaling policy last week, and is
             the change live?"

T+0       Ask the agent: "show the events for checkout-asg"
          (get_autoscaler_events)
T+30 sec  Newest rows:
            status_update  completed  (executor)
            apply          queued     ops-lead@
            update         completed  ops-lead@
          Answer: ops-lead edited it and the re-apply succeeded.
          Cross-check: Activity → Audit Logs, Resource filter
          "Autoscaler Policy", shows the same edit and apply.

QUESTION 2: "Why did checkout-asg jump from 6 to 12 instances at
             14:00 yesterday?"

T+2 min   The event log has nothing at 14:00, which is expected:
          no one changed the policy, and cloud scaling is not
          recorded there
T+3 min   AWS console → Auto Scaling groups → checkout-asg →
          Activity: three launches between 14:02 and 14:15,
          each citing the target-tracking alarm on CPU
T+5 min   CloudWatch alarm history: CPU above the 60% target
          from 14:00. Application logs: a marketing email went
          out at 14:00
T+6 min   Conclusion: the rules ZopNight applied on the 19th
          did what they were written to do. No policy change
          needed; the team adds the campaign to its capacity
          calendar

Two questions, two sources. The event log settled the ownership question in seconds; the cloud’s activity history settled the scaling question.

3. Hands-on (5 min)

Read the history of one of your policies:

□ STEP 1: Pick a policy in Automate → Auto Scaling
  Policy: __________   Status badge: __________

□ STEP 2: Pull its events (ask an agent to call
  get_autoscaler_events, or open Activity → Audit Logs with the
  "Autoscaler Policy" resource filter)
  Last edit by: __________   When: __________
  Last apply outcome: completed □ failed □   Error: __________

□ STEP 3: Confirm the live rules
  Last status_update completed after an apply? □
  Any later remove? □

□ STEP 4: Open the cloud's scaling history for the same group
  Last scale-out: __________   Rule that fired: __________

4. Knowledge check

Q1

A team wants to know why their ASG scaled from 4 to 8 instances at 03:00. Where is the answer?

A. The policy’s event log, in its scaling-action rows for that hour
B. The ASG’s own activity history and CloudWatch alarm history
C. The Anomaly Detection feed, which flags unusual scaling patterns
D. A status_update row, which records each instance the cloud adds

Show answer

Correct: B. ZopNight does not ingest the cloud’s scale-out and scale-in activity. The event log only records lifecycle actions; the cloud’s own history says which rule fired and why.

Q2

The newest row is apply with status queued, and the row before it is update. What do you know?

A. The edit has reached the cloud and the new rules are live now
B. The apply failed, because a queued row is never followed up later
C. The update was a rename only, so the apply will make no change
D. The apply was requested; its outcome arrives as a status_update

Show answer

Correct: D. Apply and remove are two-step. The queued row records the request; the executor’s callback then writes a status_update row with completed or failed, plus any error message.

Q3

Which of these is recorded in a policy’s event log?

A. A mode change from Autopilot to Manual, as an update row
B. The CPU value that triggered each scale-out on the group
C. The hourly cost of the instances the group added that day
D. The cloud’s scale-in decisions, with their start and end

Show answer

Correct: A. Every edit, including a mode change or a rename, writes an update row with the actor. Metric values, costs and the cloud’s own scaling decisions are not recorded.

5. Apply

Use the event log (the get_autoscaler_events tool, or Activity → Audit Logs filtered to “Autoscaler Policy”) for “who changed it and did it land”. Use the cloud’s own scaling history for “why did it scale”.

For your team: when a policy card shows failed, read the latest status_update error before pressing Retry apply.

Module quiz

You have now completed all six lessons of M2.4. The module quiz.

Outcome

1. Concept

The actions

The fields on each row

Where to read it

A worked log

Why did the group scale? Go to the cloud

Patterns in the event log

2. Demo

3. Hands-on (5 min)

4. Knowledge check

Q1

Q2

Q3

5. Apply

Module quiz

Related lessons

Start with the bill.