Tech Talk: Operations: Evidence, Signals & Blameless Postmortems

Session: Mon Oct 19 · Tech Talk: Operations: Evidence, Signals & Blameless Postmortems · 65 min

One spine: a real incident from this term, told from the report to the recovery. On Tue Sep 29 the staff of another course on Pawtograder wrote in to say the platform was not recording most students' submissions. It was recording all of them, and rejecting almost all of them as "identical to the starter code" because of one config file nobody had edited. Every idea today hangs off that story, so the room never has to hold an abstraction without an example under it.

The thesis, in one sentence: Whether you can answer "what happened?" is decided when you design the data and the deploy, not during the incident. The investigation was answered by rows the software kept on purpose and by a deploy config that pinned exactly what was running. The logs had expired. A metric did count the problem, but it counted the normal case in the same bucket, so no alert could be written against it.

The room is very mixed. Some of them do provisioning at a co-op; some have never opened a terminal on a server. Every term gets a definition at first use, in a blue box labeled Definition, and the warm-up is built so that everyone can contribute without knowing any of the vocabulary.

Structure: a 27-minute talk, then a 34-minute team working session. The talk was cut from about 49 minutes after Demo Day 1 (Oct 15), because the teams need class time to work through their feedback and break their projects down. Today is also the deadline for agreeing first-ticket scopes on the issue, and this is the one class where you can sign off all of them in person.

• Reminders and title (~2 min).
• Warm-up (~5 min, two slides). The real report, pairs, and sorting their answers on the board. The board stays up for the talk.
• Objectives (~1 min).
• Arc 1, What Actually Happened (~6 min, three slides). The facts, the one-line cause, and who answered each question, with what didn't help said out loud.
• Arc 2, Configuration as Code (~2 min, one slide). Why the fix was a reviewable commit, and why "which code was running?" had an exact answer.
• Arc 3, Observability (~5 min, two slides). Where Pawtograder's evidence lives, then the metric that counted the failure and couldn't tell it from normal, and the fact that would have.
• Arc 4, The Postmortem (~6 min, one slide). A blameless postmortem discussion: which action item takes a person out of the loop.
• Working session (~34 min, one slide that stays up). Feedback triage, the breakdown to Nov 23, first-ticket sign-offs while you go round the tables, and a post in each team's channel.
• Close (~3 min). Game Day 1 is Thursday.

Why it's on Oct 19. It moved from Oct 1 so it lands three days before Game Day 1 (Thu Oct 22), after teams have spent three weeks in their areas and have code to point at. There is no separate standup today: each team's post at the end of the working session does that job.

If the talk runs long, cut in this order: the tool names on the configuration-as-code slide, then "One File Nobody Edited" (say the cause in one sentence), then the Grafana demo on "The Number Was Already There". Never cut the postmortem discussion or the working session. Start the working session by minute 28.

Anonymization. No student names, no repository names, no course number on the slides. Say "another course on Pawtograder" and "a student". The two students whose rows had been activated by hand stay anonymous too.

Before class:

• Whiteboard: leave a wide space for the warm-up columns. They stay up for the talk.
• Bring each team's Demo Day 1 worksheet pile, or have the photos ready to share in their channel if the piles went home with the teams.
• Pull up the list of first-ticket issues so far, so you know who arrives without one.
• Open Grafana (Explore, Prometheus data source) in a tab if you want to show the metric live in Arc 3. The slide works without it.

Transition: Reminders first, then a warm-up.

Reminders

• TODAY: first-ticket scope agreed on the issue, before you leave
• TODAY: no standup post. Your team's working-session post replaces it
• WEDNESDAY: Reading Presentations 1, pre-reads posted today
• THURSDAY: Game Day 1: The Queue Nobody Drains, announced in advance
• THU OCT 29: first ticket review-ready, demoed at Demo Day 2

Keep this to 60 seconds. Deadlines only. Say the shape of the day once: a short talk, then most of class working in teams. The game day on Thursday is the reason this talk is today.

Transition: Now, today.

CS 4535: Software Design & Delivery

Tech Talk: Operations: Evidence, Signals & Blameless Postmortems

©2026 Jonathan Bell, CC-BY-SA

One sentence of callback. s07 ended on "a loud failure needs no test, it already tells you." Today is about the quiet failures that get past the tests and reach production, and how you find out about them.

What it unblocks. Game Day 1 is Thursday, and the Game Days after it inject faults into their own demo classes. After today they know the words for what they'll be doing in those rooms, where Pawtograder's evidence lives, and what their own project will need in order to be observable.

Transition: Before any definitions, here's an email that arrived on Tue Sep 29.

You Get This Email

We're seeing a widespread problem with Pawtograder not recording student submissions for our project assignment. Only a small number of students' submissions are actually being recorded. The vast majority of students who have pushed real, substantial changes show nothing: no score, "not submitted" on the dashboard, even though their commits are clearly real work in their GitHub repos.

Course staff of another course on Pawtograder · Tue Sep 29

2 minutes, with the person next to you. You're on call. Write down the first three things you'd check, and for each one, where the answer lives.

This is real, from Sep 29, lightly edited to remove names. Say that. The room is more engaged by a real incident on the system they work on than by any textbook case.

Read it out loud, slowly, then start the clock. No vocabulary needed. Anybody can answer "what would you check first." The room is mixed: some do provisioning at a co-op, some have never opened a terminal on a server. The students with ops experience are a resource for their pair, so say so.

Circulate and listen for the "where." Most pairs will write things such as "check if the webhook fired", "look at the database", "check the logs", "ask the student", "check GitHub", "see if there was a deploy." The second half, where the answer lives, is what makes the debrief work, so nudge pairs who only wrote the check: "and where would you look to find that out?"

Do not hint at the answer. A pair who guesses "maybe a config problem" is great; do not confirm it.

Transition: Let's put your answers on the board.

Where Would the Answer Live?

The database

Logs

Dashboards & alerts

GitHub

The code & its config

Ask a person

Keep this board. We'll come back and see which columns actually answered it.

Draw these six columns on the whiteboard, not just on the slide, and write each pair's answers into a column as they call them out. Take one answer per pair, then open it up. About two minutes.

Some answers will not fit, and that's useful. "Check whether there was a deploy" goes under code and config. "Check if the webhook fired" is interesting because it could live in three columns: logs, the database, or GitHub's own delivery history. Point that out; it foreshadows the investigation.

Count the columns before moving on. Usually logs and the database get the most answers and dashboards get a few. Say what the room predicted. In Arc 1 you'll reveal that logs contributed nothing and the database answered almost everything, and that contrast lands harder if the room committed to a prediction.

Leave the board up. It comes back in "Who Answered Each Question?" and in the postmortem.

Transition: Here's what you'll be able to do after today.

Learning Objectives

After this session, you'll be able to:

1. Explain why "what happened?" could be answered from what Pawtograder recorded and declared, and say where its evidence lives and what was already gone
2. Say what tells a failure apart from normal behavior, and why the software should record it at the moment it knows
3. Write a blameless postmortem action item, and say who has to be awake for it to work

Three, cut from five after Demo Day 1, because the talk is now about 27 minutes. 1 is Arc 1, the configuration-as-code slide and the evidence table. 2 is "The Number Was Already There". 3 is the postmortem discussion that closes the talk, and the working session applies it to their own tickets. 2 and 3 matter most.

What moved out. The incident loop belongs to Game Day 1 on Thursday, which runs it live, so today only says "mitigate before you recover" in passing, on "One File Nobody Edited". Drift is gone: nothing in this incident drifted, and Thursday's fault isn't drift either. The four-signal table stays as a map of where to look.

Don't preview Thursday. Leave queues and scheduled jobs out of today. Thursday teaches objective 3 again with a different signal, and it lands better if they get there themselves.

Loki isn't on the slides, on purpose. Pawtograder has no log aggregation in production today, and the lesson is better told as "the logs were gone" than as a tour of a tool nobody can open. The old objective about what belongs in a Sentry context is folded into the working session: "where does the answer live" is that question, asked about their own tickets.

Time. Reminders 2, warm-up 5, objectives 1, Arc 1 six, Arc 2 two, Arc 3 five, Arc 4 six: about 27. The working session starts by minute 28 and runs about 34.

Transition: So what actually happened?

Pawtograder Wasn't Losing Them

240 student repositories. 13 students had pushed. 44 student pushes reached Pawtograder, and every one was recorded.

43 of the 44 were rejected, each with the same message: "it is identical to the assignment's starter code." 40 of those were real work.

One rejected push was a 10-file change. And one student the staff named as "working" had a submission with no files at all: someone had clicked "make active" on a rejected row.

The report said "not recording." The first query said otherwise. The submissions table had a row for every push. What the report called "nothing" was a row marked inactive, with an error attached, that the dashboard showed as not submitted.

Say what this means about reports in general. A user describes the symptom they can see. "Not recording" was a reasonable reading of the dashboard, and it was wrong about the cause. Triage starts by checking the claim, not by accepting it.

The third box is worth one sentence. The staff had named two students as "confirmed working." One had a real accepted submission. The other had a rejected, fileless row that the student and then a grader had manually made active. The dashboard said "submitted"; there was no code behind it. Evidence from a user can be wrong in both directions.

Why the rows existed at all is the first software decision in this story. An earlier version of this code deleted a rejected push. Somebody changed it to keep the row and attach the reason, because deleting it made the failure invisible to the student. That change is why this investigation took an afternoon rather than a week.

The counts are as of Tuesday afternoon, and they are student pushes only. Course staff had also pushed seven test commits, and those went through, because staff pushing to their own repository are exempt from the empty check. That exemption is part of why the staff saw it working. Three of the 43 rejections really were empty (one added only a .env file, one only a test.txt), which is why 40 were real work. If anyone asks why 240 repositories and only 13 students: the assignment was a week from its deadline.

Transition: So why would a 10-file change look identical to the starter code?

One File Nobody Edited

The assignment's pawtograder.yml, in the course's grader repository:

submissionFiles:
  files:
    # The default is to submit all java, arr, md, and python files.
    # You should almost definitely change this.
    - '**/*.java'
    - '**/*.arr'
    - '**/*.py'
    - '**/*.md'

The project is TypeScript. Pawtograder decides "empty" by comparing only the files these patterns match against the starter code. In the starter code, that's one file: README.md.

Any push that didn't touch a Markdown file looked identical. The one student who added a .md file got through.

Let the comment in the file do the work. Read "You should almost definitely change this" out loud and pause. The template shipped a warning, in a file nobody had a reason to open after the assignment was created.

Explain the check in plain terms for the mixed room. For an assignment that doesn't allow empty submissions, Pawtograder hashes the student's files and compares the result with a hash of the starter code. It only looks at the files the patterns select, so that a changed lockfile or a stray build output doesn't count as work. If the patterns select the wrong files, the comparison is between two things that were never going to differ.

Whose fault is it? Nobody's, and say that. The template default was reasonable for the Java and Python courses it was written for, the staff had turned the autograder off and had no reason to open the file, and the platform did exactly what the config said. It's a systems failure: a default that is safe in one context and silently wrong in another, with no signal when it goes wrong. That framing is what a blameless postmortem looks like, and Thursday's postmortems use it.

The fix was one commit to this file. New pushes were accepted within a minute. The 40 already rejected stayed rejected, and restoring them took a reviewed script, run as a dry run first, then on one repository, then on the rest. Say the rule in one line, because Thursday needs it: mitigate before you recover. Stop new harm first, then repair what's already broken.

Transition: Let's go back to your board. Which of your columns answered this?

Who Answered Each Question?

Question	Where the answer lived	What put it there
Can I look without breaking anything?	A read-only replica of the database, and a narrowly scoped cluster login	Infrastructure decision
Were the pushes recorded?	Submission rows, kept on purpose when rejected	Software decision
Why were they rejected?	An error row with a machine-readable type: empty_submission	Software decision
What was it comparing?	The config, copied into the database, and the stored hash of each starter file	Software decision
Which code was running?	The image tag pinned in the deploy config, which names one commit	Infrastructure decision
Who made the empty row "active"?	An audit table of every change, with who made it	Software decision
Did any pushes go missing?	GitHub's record of pushes, compared with ours	Outside: our logs were gone

Almost every answer was in the database, because someone designed it to be there.

Point at the whiteboard for each row. "Database" column: rows 2, 3, 4 and 6. "Code and config": row 5. "GitHub": row 7. "Logs": nothing. "Dashboards": nothing. Say the count, and compare it with what the room predicted in the warm-up.

Explain the two infrastructure rows in one sentence each. A replica is a live, read-only copy of the database; you can run any query against it with no risk of changing a student's grade. The cluster login let me read pods and connect to the database, and nothing else, because it was written that way. Both are decisions someone made months ago so that an investigation like this one could be safe.

Row 7 is the interesting one. To check that no pushes had been dropped on the way in, I needed a record of every push. Pawtograder's own logs keep about two hours. GitHub keeps pushes indefinitely. So the only trustworthy answer came from outside our system.

This is the thesis; say it plainly. Whether you can answer "what happened?" was decided long before Tuesday, by people choosing to keep a rejected row, record an error type, keep an audit trail, and pin an image tag. None of those were built for this incident.

Then say what didn't help, in three sentences. Logs: Pawtograder keeps a pod's logs for about two hours, and the first rejection was six days earlier. Alerts: production has 37 rules, and none is about rejected submissions. Detection: the first thing that noticed was a person, six days in, writing an email. Someone decided each of those, and Arc 3 comes back to the alert.

Transition: Two of the answers came from how Pawtograder's infrastructure is written down. Let's define that.

Why the Fix Was a Commit

Definition. Infrastructure as code (IaC) means the servers, containers, networks and settings a system runs on are described in files under version control, and a tool makes the running system match those files. You change the system by changing a file, not by clicking in a console.

In Pawtograder

• A Helm chart (a template for Kubernetes resources) plus one values file per environment, such as values-prod.yaml
• Kubernetes itself: every service is a file describing what should run
• pawtograder.yml per assignment: configuration as code, the same idea for app settings

What it buys you

• Review. A change to production is a pull request
• Reproduce. Staging and previews come from the same files
• Answer. "What is running?" has a written answer

One slide, about two minutes. It's the first new term for half the room. The contrast is the useful part: the alternative to IaC is a person logging into a server or a web console and changing a setting by hand. That works, once, and then nobody can tell what was changed, when, or why, and nobody can build a second copy.

Name the tools only as examples, in one breath. Terraform describes cloud resources, Helm and Kubernetes manifests describe what runs in a cluster. The Workspaces team will meet several of these in their own namespace this month.

Configuration as code is the same idea one level up. The file from Arc 1 is configuration as code: the grader settings for an assignment live in a git repository, and a webhook copies them into the database when you push. The fix for the incident was a commit, which means it was reviewable and it's in the history.

The first and third "buys" are today's point. Review: the fix was one commit, reviewable and in the history. Answer, in one sentence: values-prod.yaml pins the edge functions to the image tag main-20260927-38db5c7b, and 38db5c7b is a commit, so I could read the exact code that rejected those pushes. Today's main might have a fix that wasn't deployed yet. The alternative is tag: latest, and then nobody can say which code is running. Sentry tags every error with the commit for the same reason (s06).

Say plainly that the files were right about what was running. Production ran exactly what they said. The webhook copied pawtograder.yml faithfully, and the pinned tag matched the deploy. The failure was a correct declaration of the wrong thing, which is why writing it down wasn't enough: nothing checked whether what was declared made sense for this course. Hold that for the postmortem.

Transition: The files told us what was running. Here's where the rest of the evidence lives.

Where the Evidence Lives

Definition. Observability is how well you can answer a new question about a running system from what it already records, without shipping new code. What it records is telemetry.

	Answers	Pawtograder today
Errors	What broke, where, in which release, for whom	Sentry → Bugsink, every event tagged with the commit
Logs	What happened, line by line, in one process	Only what a pod still holds: about two hours
Metrics	How much, how often, how fast, over time	Prometheus, graphed in Grafana, with 37 alert rules
Traces	Where one request spent its time, across services	Off

Definition. An alert is a rule over telemetry that notifies a person when it's true: "this number has been above that line for ten minutes."

Two definitions, and the first one needs care. Observability is not a tool. It's a property of the system: can you answer a question you didn't plan for? Monitoring is the part you did plan for: the dashboards and alerts someone set up in advance. The incident was a question nobody planned for.

Walk the table row by row, one sentence each, and connect each row to the incident.

• Errors: they've seen Sentry in s06. A rejected submission isn't an exception, so nothing went to Sentry. The code was working as written.
• Logs: the most detailed record, and the one that disappears. With nowhere to send them (Loki, Elasticsearch, a cloud logging service), they vanish when the pod restarts or the buffer rolls over.
• Metrics: cheap, kept for weeks, and good for "is something changing?" They lose the details: a metric can tell you rejections went up; it can't tell you which student.
• Traces: off, because they cost storage and nobody has turned them on. s06 said this.

Mention the database as a fifth source without adding a row. Arc 1 showed most answers came from rows the software kept on purpose. That's telemetry too, in the widest sense, and it's the kind students will design into their own projects.

Treat the table as a map for Thursday. The column they need is the right one: where Pawtograder keeps each kind of evidence, and the one that's already gone after two hours. The Grafana and Sentry here are production's. Don't say anything about staging's monitoring; Thursday covers it.

Transition: Here's the metrics row, applied to Tuesday.

The Number Was Already There

Pawtograder already publishes this metric, every minute, per course:

web_workflow_errors_recent{class_id="…", category="empty_submission", window="1h"}

For six days it counted one course's pushes being rejected as empty. Of the 37 alert rules, none looks at it.

It also counts every new repository's first push. That push is the starter code, and rejecting it is correct. A misconfigured course and a normal Monday look the same in this number.

Normal. The commit changes nothing compared with the starter code.

Misconfigured. The commit changes files, and none of them match submissionFiles.

The software knew the difference at the moment it rejected the push.

This is the pivot of the session. The room just learned that metrics exist and alerts exist. Here they are, both present, and not connected. The obvious reading is that someone forgot to write the alert. The real problem is that nobody could have written a good one.

If you have Grafana open and the clock allows, show it. Explore, Prometheus, paste the metric name, filter to category="empty_submission", and set the range to the last seven days. A real line is more persuasive than any slide. Check it before class: it is a one-hour window, so it shows bursts rather than a steady climb. If you don't have it open, the slide is enough.

Explain the name for the mixed room. Everything in the braces is a label: which course, what kind of error, over what window. One metric name, many time series, one per combination of labels. That's what lets one alert rule cover every course.

Why wasn't there an alert? Because empty_submission is mostly normal. Creating a student's repository from the template triggers a push of the untouched starter code, and that is rejected as empty, correctly, for every student in every course. Students who push before starting add more. So the count jumps every time an assignment is released, and a course with 200 students produces 200 rejections on day one without anything being wrong. The misconfigured course produced 43 over six days. Any threshold low enough to catch that pages someone at every release, and gets muted within a week.

Then reveal the two boxes, without asking the room. Say what tells them apart: the webhook already has both facts in hand when it rejects a push, the files the commit changed and the files the patterns selected. The first push from the template changes nothing. The misconfigured course's pushes changed TypeScript files the patterns never looked at. Recording those as a separate category is one branch in the webhook.

Say the general lesson, then the last line. A metric can only answer questions its labels can tell apart, and here the failure and the normal case share one. Recording the distinction at the moment the software knows it is the same move as keeping the rejected row in Arc 1. Who it should be told to is the postmortem's question.

Transition: Detection is the step that failed on Sep 29. So, the postmortem: what do we change?

Blameless Postmortem: What Changes?

Definition. A blameless postmortem assumes everyone acted reasonably on what they knew, and asks what in the system let the failure happen. Its output is action items: changes that make it not happen again.

What let it happen: a default that was right for Java and wrong for TypeScript · a file nobody had a reason to open · no signal to anyone for six days

4 minutes, whole room. Write one action item. Who has to be awake for it to work?

Action item	Who has to act
Page an operator when a course's pushes change only ignored files	An operator, who then emails the course staff
Tell the course staff directly, on their dashboard	The staff, who own the file
Tell the student at push time: you changed 10 files, and this assignment only collects .java, .py, .md, .arr	The student, who asks a TA that day
Check the patterns when the assignment is created: they match only README.md in this starter	Nobody. It never ships
Default the patterns from the starter's own files	Nobody

Each row down takes a person out of the loop. The alert is the top row.

This is where the talk ends, so give it the time. About six minutes. Let the room argue. Thursday runs the whole incident loop live; today is about what we'd change.

Say why blameless first, in two sentences. The blame version of this postmortem is "the staff should have read the comment in the file." Its action item is "remind instructors to check submissionFiles", which needs a person to remember, every term, forever. The blameless version asks what made the mistake easy and the failure quiet, and those are things we can change in code.

Take action items before revealing the table. Expect "add an alert" first, because the last fifteen minutes were about metrics. For each one, ask the slide's question: who has to be awake? An alert pages an operator, who doesn't own the file, doesn't know the course, and has to email the people who do. That's a person added to the loop, at the worst time.

Reveal the table and read it top to bottom. Map the rows back to the three causes. "No signal" is the first three rows, and they get better as the message moves toward the person who can act on it: the student knows within seconds, and the staff can fix it the same day. "A file nobody had a reason to open" is the fourth: check it when someone is already looking at it. "A default right for Java" is the fifth: make the default come from the starter itself. The distinction from the last slide powers every one of the first three. Recording it was never only about the alert.

Be honest about the trade. The lower rows cost more to build and need product decisions: what should the student see, and should creation-time checks block or warn? An alert is cheap and fast to write, so it's often the first action item, and that's fine as a stopgap. It's the right final answer only when nothing lower on the table is possible. A postmortem whose only action item is an alert has usually stopped one question early.

These rows are candidates, not commitments. If any has shipped or been filed since Sep 29, say so and link it. Several would make good tickets.

Connect forward. Thursday's game day ends with a postmortem, and it has to name a prevention item. Push them toward the lowest row they can reach. The same question is the second step of the working session, about their own tickets.

Transition: That's the talk. The rest of class is yours, as teams.

Working Session

1 · Read your feedback (7 min)

Sort your Demo Day sheets into four piles:

• questions you couldn't answer
• findings people didn't believe
• pushback on a risk or a cut
• the "not yet" reasons

Pick 2 or 3 to act on.

2 · Break it down to Nov 23 (15 min)

Each milestone becomes team: issues. Every issue has:

• an owner and a size
• the milestone it belongs to
• one line: how would we know it broke, and who finds out first?

3 · Your first ticket (while you work)

I come to each table. Before I leave it, every member's scope is written as a comment on their issue, and I've agreed to it there.

4 · Post it (last 5 min)

In your team channel:

• what you're changing because of the feedback, and why
• a link to your issues, filtered by milestone
• each member's first-ticket issue

Leave this slide up for the whole session. Teams sit together. Call the time at 7 and at 22 minutes, and again 5 minutes before the end of class.

Step 1: the feedback. Each team has its own pile from Thursday, or the photos. The four piles match the worksheet's prompts. Push for 2 or 3 items they will act on, each with a reason, and let them disagree with the room: "two people didn't believe our finding, and here's the trace" is a fine answer. The "not yet" pile is the most useful one, because it says what the room needed to see before Monday.

Step 2: the breakdown. The scope and the cut they showed on Thursday become issues. The "how would we know it broke, and who finds out first?" line is the postmortem table, applied before anything breaks. If the answer is "an operator, from an alert", ask whether the user or the staff could be told directly instead. When they write "the logs", push back with Tuesday: the logs are gone in two hours. Where does it live that you'd still have in a week? "Nowhere yet" is a good answer, because it's a design decision they can make this month. That line is also the first draft of the ops playbook that Feature Freeze (Nov 23) asks for.

If a team is stuck on that line, give them the email they'll get in November:

• Paper Exams. "We uploaded 300 scans and some students have no exam." Unmatched scans per exam (a row they can count), how long the oldest unprocessed batch has waited, LLM provider errors, and how often a human overrides the suggested score.
• Cloud Workspaces. "I clicked Open and it just spins." Time from click to a usable workspace, a synthetic readiness probe, and Forgejo webhook deliveries compared with the submissions they should produce. #981 is already a "ready" that isn't.
• Office Hours. "The queue says I'm 3rd. I've been 3rd for 40 minutes." Realtime connections and reconnects per course, the delay between a database change and the client seeing it, and time from raised hand to helped.
• Usability & Permissions. "It let me click it, and then it said no." Who may do what is written twice, in the UI and in database policies, and the two disagree (#983, #996, #1010). Today the user finds out first, after the click. Permission denials by page and role would tell the team; checking the policy before showing the button would mean nobody has to find out. Also axe violations over time in CI, and abandoned flows.

Usability and Cloud have the thinnest backlogs, so step 2 matters most for them. Expect them to file in the room.

Step 3: first-ticket sign-off. Today is the deadline for agreeing scopes on the issue, so this is the real reason for the session. About 8 minutes per table. For each student: the issue, the "done" sentence with a user in it, which layers it touches, and the stacked PRs they plan. Agree to it in a comment on the issue before you move on. Start with Cloud, where people are most likely to arrive without a scoped ticket. Pool claims from the Agents Activity carry over. #467 and #1026 were still free as of Oct 14.

Step 4: the post. It replaces today's standup, so there's no separate standup post this morning. Read the four posts tonight. Anyone without a first-ticket link in their team's post gets a message from you tomorrow.

Transition: Call time 3 minutes before the end, then close.

Up Next

Wed Oct 21, Reading Presentations 1

Then Thu Oct 22, Game Day 1: The Queue Nobody Drains. It's announced, and the response is narrated. Bring what you learned today.

Before then:

• Pre-reads for Wednesday's presentations, posted today
• First ticket: scope agreed on the issue today. Start the first PR in the stack this week
• Observability: your function responds first on Thursday. Have Grafana and Sentry open

Three minutes. Close on Thursday. When something goes wrong in the game day, they'll know where to look, and they've already started deciding what their own tickets will let them see.

Game Day 1 is mid-window for the first ticket. Say it: a ticket that has its first PR open before Thursday is in good shape. One that hasn't started by Friday is the one that opens a PR at midnight on Oct 28.

Check the Observability function has access to Grafana and Sentry before Thursday. It's on your list.