Turn Kubernetes warning events into Asana tasks
A Kubernetes + Asana agent flow
A pod that keeps failing its readiness probe or hitting OOMKilled emits a warning event every few minutes, and those events age out of the cluster after an hour. Whatever caused them is still broken; the record is just gone. This recipe captures the signal before it expires. The agent calls events_list, filters to the warning-type events that matter, and creates an Asana task with create_tasks: the reason and object in the title, the message and namespace in the notes, and a due date so it lands on someone's plate. Kubernetes returns the current event window when the agent asks rather than streaming it, so the agent polls on a short loop and dedupes on the event's involved object plus reason, so a CrashLoopBackOff firing every minute becomes one task, not sixty.
The flow
events_listList Kubernetes events (warnings, errors, state changes) for debugging and troubleshooting in the current cluster.
create_tasksCreates up to 50 tasks with assignments, dates, and custom fields.
Step by step
- List cluster events
The agent calls events_list, which returns the current events: warnings, errors, and state changes with a type, reason, involved object, message, and timestamp. It filters to Warning-type events like OOMKilling, BackOff, FailedScheduling, and Unhealthy.
- Collapse the repeats
One failing pod emits the same event over and over. The agent keys on the involved object plus the reason, so a recurring CrashLoopBackOff for a single pod maps to one task. The Kubernetes count field tells you how often it has fired.
- Create the Asana task
For each new distinct issue the agent calls create_tasks in your ops project: title from the reason and object (FailedScheduling on payments-7d9), notes with the message, namespace, and fire count, and a due date. Several distinct issues from one poll batch into a single call.
Tell your agent
Every two minutes, call Kubernetes events_list, filter to Warning events with reasons like OOMKilling, BackOff, or FailedScheduling, dedupe by involved object and reason, and create an Asana task for each new issue with the message, namespace, and fire count in the notes.
Setup
This flow needs both servers connected to your agent. Follow each install guide:
Worth knowing
- events_list returns the current event window the cluster retains, typically about an hour, not full history; poll often enough that windows overlap or a short-lived warning can expire before the agent reads it.
- A single bad deploy can produce hundreds of events across pods. Dedupe on object plus reason before filing, or one rollout buries the Asana project under near-identical tasks.
Questions
- Can one call file several tasks at once?
- Yes. create_tasks handles up to 50 tasks per call, so when a poll surfaces several distinct cluster issues the agent batches them into one request instead of one per event.
- How do I avoid a task for every restart?
- Dedupe on the involved object and reason and read the event's count field. A pod restarting fifty times is one task with count 50 in the notes, not fifty tasks.