Activity
Activity is the record of what the platform has done for your account — every generation, deployment, import, plugin change, schedule run, and sign-in, newest first. Reach for it when you want to know what happened and when, whether something is still running, or why a Work no longer looks the way you left it.
The page lives at /activity and holds three views: Log (what already happened, as an audit table), Live Feed (the same history read as plain sentences about who did what) and Schedules (what is set to happen).
Which view you want
| You want to… | Go to… |
|---|---|
| See everything that happened across all your Works | Activity → Log |
| See everything happening on one directory, visitors included | that Work's own Activity Feed tab |
| See what one Work's repos, trackers and chats have done | that Work's External activity panel |
| Read what your agents have been doing, one line per thing | Activity → Live Feed |
| See what is going to run next, and when | Activity → Schedules |
| Stop a generation that is running right now | Activity → Log, then Stop on the running row |
| Pull the history into a spreadsheet | Export CSV, in the Log view |
The Log and the per-Work Activity Feed are not the same list — see Per-Work feed vs the global Log.
The Log view
Entries are ordered newest first and paginated 25 to a page. In the Log view the page refreshes itself every 5 seconds: the summary cards always, and the table rows when you are in Table view. The timer stops while the browser tab is in the background and fires an immediate refresh when you come back, so a running generation updates without you touching anything.
Columns
| Column | What it holds |
|---|---|
| Date / Time | When the entry was recorded. |
| Work | The Work it belongs to, as a link. Account-level events (login, signup) show —. |
| Type | The kind of event. |
| Summary | A one-line description. A completed generation summarises what it added and changed, or reports no item changes — with the item total either way. |
| Status | Pending, In Progress, Completed, Failed, or Cancelled. |
Click any row to expand it. The panel shows the exact Action, the status, the creation time, and — when the entry carries them — Details, Metadata, and a Raw JSON dump. While an expanded row is still In Progress, the platform re-fetches that one entry every 3 seconds (paused when the tab is hidden); for a running generation that is where Live Logs stream in.
Table and Board
The Table / Board switch sits in the page header. Board groups the same entries into five status columns (Pending, In Progress, Completed, Failed, Cancelled); each column shows 15 cards with a button below it that reveals 15 more at a time, and clicking a card opens the same detail panel as a dialog.
Board has no pagination. It loads the newest matching entries in batches of 100 — the API's maximum page size — and stops at 500. The number on each column header counts only the cards that were loaded, so on an account with more than 500 matching entries those numbers sit below the number of entries that actually match.
Board is also outside the 5-second refresh: it reloads only when you change a filter or switch views, while the summary cards above it keep updating. A Board left open drifts out of step with them — switch to Table and back to reload it. Stopping a generation from a Board card refreshes the table and the cards, not the board.
Your Table/Board choice and your Log/Schedules choice are remembered in the browser. The filters and page number live in the URL instead (?actionType=…&status=…&search=…&page=…, plus ?view=schedules), so a filtered view is a link you can share or bookmark.
Stopping a running generation
Rows whose type is Generation and whose status is In Progress carry a red Stop button, in both the table row and the Board detail dialog.
There is no confirmation dialog. The cancel request goes out as soon as you click, and the button locks for 10 seconds afterwards. If the run happened to finish in the meantime, nothing is cancelled and the list simply refreshes. See Generation Cancellation for what the platform does with the request.
Summary cards
Five cards sit above the filters — In Progress, Completed, Pending, Failed, Cancelled. Clicking one applies that status as a filter; clicking it again clears it.
The counts are always your account-wide totals per status. They do not shrink when you type in Search or pick a Type — only the list below them responds. A search that returns three rows can still sit under a card reading "Completed 4,812".
The "Showing 1 to 25 of …" line below the list does give you the filtered total — but it appears only when the filtered result runs to more than one page, and never in Board view. When the result fits on a single page, the rows on screen are the count.
Filters
| Filter | What it matches |
|---|---|
| Search | The entry's summary or the Work's name. Case-insensitive, matches anywhere in the text. |
| Type | One event type, chosen from the dropdown. |
| Status | Pending, In Progress, Completed, Failed, or Cancelled — the same values as the summary cards. |
The three combine with AND: a search of deploy with Type Deployment and Status Failed returns only failed deployments whose summary or Work name contains "deploy". Search is applied after a short pause in typing, so results settle a moment after you stop. A Clear filters button appears next to the filters whenever any of them is set.
The Type dropdown offers: Generation, Comparison, Deployment, Work Created, Work Updated, Work Deleted, Plugin Enabled, Plugin Disabled, Plugin Configured, Member Invited, Schedule Executed, Import, Login, and Signup.
The platform records many more event kinds than the dropdown offers — item changes, settings updates, data-sync outcomes, template and knowledge-base events, member role changes, and schedule create/update/delete among them. Those entries appear normally in the list and in the export, but you cannot select them in the Type filter. Use Search to find them by their summary text.
Whether one of these entries still gets a readable badge depends on a separate label list, not on the dropdown: a member role change reads Role Changed, while a website-ingested signup has no label at all and falls back to the raw value with underscores turned into spaces — Website User Registered.
The underlying API accepts a date range, but the Activity page never sends one and exposes no date picker. The Date / Time column is not sortable either. The list is already newest first, so the only ways to reach a particular period are to page back through it, or to export to CSV and filter there.
Exporting to CSV
Export CSV sits in the page header in the Log view (it is hidden while you are on Schedules). It downloads a file named activity-log.csv.
The export reflects the filters you have applied. Search, Type and Status are all carried into the download, so what you get matches what you are looking at — not your whole history.
It exports every matching row, not just the current page, with these six columns:
| Column | Contents |
|---|---|
| Date | Full ISO 8601 timestamp in UTC, e.g. 2026-08-14T09:31:07.482Z. |
| Action Type | The event type as a raw value (generation, work_created, …). |
| Action | The specific action recorded for the entry. |
| Status | pending, in_progress, completed, failed, or cancelled. |
| Work | The Work's name, or empty for account-level events. |
| Summary | The same one-line summary shown in the list. |
Two things about the file are worth knowing before you open it:
- Action Type and Status are raw values, not the labels on screen. The CSV says
in_progresswhere the page says "In Progress". Build spreadsheet formulas against the raw values. - A leading apostrophe may appear on some cells. Every column except Date passes through a formula-injection guard: a value beginning with
=,+,-,@, a tab or a carriage return is prefixed with'so spreadsheet software renders it as text instead of running it as a formula. The apostrophe is not part of your data.
A single download returns at most 10,000 matching entries, and it gives you no warning when it truncates. If your log is larger than that, narrow the filters — by Type or Status — and take several exports rather than one.
The Schedules view
The Schedules toggle in the page header swaps the log for everything scheduled to run across your account, gathered from every source in one list: Recurring task, Agent heartbeat, Work schedule, Mission tick, Source validation, Data sync, and Inbound trigger.
Each row shows Owner (a link to the thing that owns the schedule), Cadence, Next run, and Status — Active, Paused, Disabled, Error, or Ended. Filter chips across the top narrow the list by source and carry a count each; a source with nothing scheduled gets no chip at all. An Active only checkbox hides everything currently switched off. The list is fetched once when you open the view — there is no polling here; reopen the view to refresh it.
You cannot pause, edit, or delete a schedule from this page. Follow the Owner link to the Work, Agent, Mission, or Task that owns it and change it there. The one exception is Inbound triggers, below.
Inbound triggers
Below the schedules list is the Inbound triggers panel — signed webhooks that spawn a Task when something external fires them. Here you can create a trigger, pause or resume it, rotate its signing secret, and delete it. Creating one gives you the webhook URL, the signing secret, and a ready-to-run signed-request example.
This panel is the small half of the feature. The full surface is the Triggers tab of the Tasks page (/tasks/triggers): a detail page per trigger, the fire log, Test fire and Fire now, triggers that match an ingested platform event instead of exposing a URL, and a declared payload contract that deliveries are validated against. See Inbound Triggers.
Copy it before closing the reveal panel — it is never displayed again.
Rotate secret is deliberately not a hard cutover. It mints a new secret, demotes the current one to previous, and the previous one keeps verifying signatures for 24 hours — so callers can roll over on their own schedule instead of failing the moment you click. After that window only the new secret is accepted. There is no confirmation step, and the new secret is revealed the same once-only way.
Rotating twice inside the same 24 hours does not give you two live old secrets: each rotation overwrites the stored previous one, so the older secret stops working immediately. Roll your callers over before rotating again.
Delete does ask for confirmation, and it kills the webhook URL for good.
The Live Feed view
Live Feed reads the same activity records as the Log, one narrated line per entry, newest first: who did it (an agent, you, an external source or Ever Works itself), what happened, a kind label and how long ago. It adds no second record of anything — every line is an entry you could also find in the Log.
- Kinds. Every line is one of five kinds: work, decision (something waiting on you, such as an Inbox item), delivery (something finished and shipped, such as a merged pull request or a completed deployment), problem (anything that failed, was refused or hit a limit) and system (settings, plugins, connections, sign-ins). A failed entry is always a problem, whatever it was about.
- Filters. Pick agents from the chips (the busiest twelve are shown; the rest are behind +N more), toggle kinds, or tick Only failed. You can watch up to 20 agents at once; a 21st is refused with a message rather than silently dropped. Filters live in the URL (
?view=feed&agents=…&kinds=…&failed=1), so a filtered view is a link you can share, and your last filters come back the next time you open the view without any. - Opening a line. A line opens the most specific thing it is about — the run, the task, the mission, the idea, the agent, the Work, the skill or the Inbox item. A line with nothing left to open (for example about an agent that was since deleted) is plain text.
- Reading back. Older entries load as you scroll, or with Load older. The view reads back 90 days; past that, or after 20 pages in one visit, it stops and points you to the Log.
- Who did it. A line names the actor as it was when the entry was written, so renaming or deleting an agent later does not change its past lines. That holds for entries that saved the actor's name when they were written, as new entries normally do. Entries from before Live Feed saved no name: they show the agent's current name, so renaming the agent changes them too, and once the agent is deleted they read "A deleted agent". Something you did to an agent — exporting or importing it, for example — is your line, not the agent's; it still shows up when you filter by that agent and still opens it.
- Refreshing. The view checks for new entries every 10 seconds while the tab is in the foreground. When more arrived than fits one page, it loads everything between the newest entry and what you already have, so nothing is skipped; after a very large burst it starts the list over from the newest entry instead, and Load older reaches the rest.
Keyboard, when no text field has focus: j / k move between lines, Enter or o opens the selected line, Esc clears the selection, a opens the agent picker, 1–5 toggle the kinds in order, x toggles Only failed, and Shift+L loads older entries.
Per-Work feed vs the global Log
Every Work has its own Activity Feed tab, and it is a different list from /activity:
| Activity → Log | Work → Activity Feed | |
|---|---|---|
| Scope | Everything across all your Works | One Work |
| Sources | The platform activity log | The platform activity log, that Work's generation history, and deployed-site events |
| Filters | Search, Type, Status — all applied by the server | Category chips (server-side), Status (browser-side) |
| Export | CSV | None |
| Paging | Numbered pages, 25 per page | 25 per page over what is loaded; Next fetches the next batch at the end |
The feed's category chips are All, Generation, Items, Deployment, Settings, Comparisons, Community PR, Users, Submissions, Reports, and Sync. A Refresh button forces an immediate reload; otherwise the feed polls every 5 seconds and backs off — up to six times the interval — while the API keeps failing.
Where the deployed site's events land
Each Work carries an activity sync mode, set on the Work's Settings page (and in works.yml as activity_sync.mode). It decides how visitor events from the deployed directory site reach the platform — and therefore whether they also show up in the global Log:
- Pull (the default) — the platform fetches events from the deployed site over an HMAC-signed request. Nothing is stored, so those events appear only in that Work's Activity Feed tab. The fetch happens on every feed request, not once per visit: because the feed polls every 5 seconds, an Activity Feed tab left open on screen keeps hitting your deployed site on that interval. It is skipped for the chips that have no deployed-site events to ask for — Generation, Deployment, Settings, Comparisons, Community PR and Sync.
- Push — the deployed site POSTs each event to
/api/activity-log/ingest. They become ordinary activity-log rows attributed to the Work's owner, with status Completed, so they do appear in the global Log alongside everything else. - Disabled — the deployed site is never consulted. The Users, Submissions and Reports chips are empty unless the Work was in push mode earlier: rows ingested then are ordinary activity-log rows, and switching the mode does not remove them.
The ingest endpoint enforces the mode: a push aimed at a Work that is not in push mode is rejected as a mode mismatch rather than quietly recorded.
Unlike the Log, the per-Work feed filters by status in the browser, over the entries fetched so far — it does not go back to the server for more. Selecting "Failed" on page 1 will not surface a failed entry that lives further back in the history; page forward first to load it.
Pull-mode entries fetched from the deployed site carry no status at all, so they vanish from every status selection except All. Push-mode website events are ordinary log rows with a status of Completed, so they behave like everything else.
If a pull-mode Work's deployed site cannot be reached, a banner names the reason, tells you what to do about it, and shows when the last successful sync was. Push-mode and disabled Works never raise it. When the problem is one that will not clear on its own, the Users, Submissions, and Reports chips are dimmed so you do not keep clicking into empty tabs.
External activity from your connectors
Below the feed, on the same /works/:id/activity page, sits the External activity panel: the commits, pull requests, tracker issues, docs pages, chat messages and meeting recordings that the connectors ingested and routed to this Work.
Each row carries the producing plugin id as a chip (slack-connector, jira-connector, github), the event kind with its source prefix stripped (github.pr.review reads as "pr review"), the event title, the actor who caused it, when it happened, and — when the connector captured a link — an icon that opens the original in the source system.
The filter chips above the list are built from the sources actually present in this Work's events, so a newly enabled connector shows up without anyone editing a list; All sources is always the first chip. Picking a chip re-queries the server (GET /api/ingest/events?workId=&source=) instead of filtering the rows already on screen, so the chips stay right as the history grows past one page. The panel asks for 50 rows at a time.
These rows come from the ingest spine, not the activity log. They are not in Activity → Log, not selectable in the Type dropdown, and not part of the CSV export. The panel does not poll either: it loads when you open the tab, and again each time you pick a chip — reload the page to refresh it.
The endpoint applies your owner scope first and unconditionally, so a Work id you do not own returns an empty page rather than someone else's events. When the panel is empty the usual reason is that no connector has claimed this Work's repository, channel or project yet — see Connectors and Integrations.
Getting the same activity pushed to you
Activity is a page you visit. A digest is the same history delivered without you asking: one message covering the last 24 hours (daily) or the last 7 days (weekly), counting the agent runs that finished, the tasks that reached done or review, the pull requests that opened, the events that arrived from your connected sources — the same ingested events the External activity panel shows per Work — the escalations still waiting on you, and where your goals stand.
Digests are off by default. Turn one on at Settings → Digest (/settings/digest); it then arrives in-app and on your notification channels. A digest is scheduled on its own, so it is not one of the seven sources aggregated into the Schedules view above. See Digests.
Known layout trap
Below 768px — phones and split-screen — the AI chat drawer stops being a side panel and opens as a full-screen overlay on top of the page, including Export CSV and the Table/Board switch in the header. Close the drawer or widen the window if a button will not take a click.
Related
- Generation Cancellation — what happens after you press Stop.
- Scheduled Updates — setting up the Work schedules that show in the Schedules view.
- Missions — Mission ticks are one of the schedule sources listed here.
- Work Changelog — the per-Work record of content changes.
- Data Management — exporting and moving your data more broadly.
- Inbound Triggers — the full trigger surface behind the panel in the Schedules view.
- Connectors — the plugins that produce the events in the External activity panel.
- Integrations — the Slack app, GitHub pull-request review, and the event envelope itself.
- Digests — the daily or weekly briefing built from the same activity.