Activity and failures

Klyo records every change as an Action, so there is always an answer to "what happened, who did it, and did it work". Those Actions feed three things: the activity feed, the failure console, and notifications.

What works today

All of it is wired: Action capture on every change, the org activity feed, the cross-org failure console with acknowledge, the in-app notification center, and email on completion.

Actions

Every operation that changes data opens an Action. It records:

• What ran: a type and a human title, like "Created campaign Spring".
• What it touched: the resource, so you can jump straight to it.
• Who ran it: a person or the system.
• When: start, end, and duration.
• How it ended: running, succeeded, or failed, with the error if it failed.

For a generation or render Action, platform admins can also open the actual request sent to the provider (Google or Creatomate). See Administration.

Long-running work (like setting up an Organization) stays running until the background job settles it, so the feed reflects reality rather than guessing.

The activity feed

Your dashboard's Activity tab is your Organization's feed, newest first. You can filter by status and see a failed row's error inline, then open it for the full detail. It is the first place to look when you are not sure whether something went through.

The failure console

Platform admins get a cross-org view built for catching problems early. It counts failures in the last 24 hours, lets you filter to just the failed Actions, and shows stat cards for running, failed, and succeeded.

When you have looked at a failure, you can acknowledge it. Acknowledging marks it triaged and clears it from the 24-hour badge, without deleting it: the Action stays in the record with its full detail. See Administration.

Notifications

Notifications tell the right people when something they care about finishes.

• In-app: a bell in the top bar with an unread count, and a notification center listing your notifications. You can mark them read, mark all read, or dismiss them. A running job's notification updates in place when it settles.
• Email: for some Action types, you also get an email when the job finishes, succeeded or failed (not while it is still running).

The push and pack activation notifications fire on failure only by default, since the toast and the feed already confirm a success. A notification click lands on the thing it is about: an activation outcome on the Activation queue's History tab, a connection alert on the Organization's Connections tab.

You control this per Action type in Settings, with a grid of in-app and email toggles. Each cell shows the default and lets you override it.

Emails send through the platform's SMTP relay once an environment has credentials configured; without them every message is written to the server console instead, so an unconfigured environment never sends real mail. Each sent mail is queued and delivered in the background with automatic retries.

What you can do today

• See every change in your Organization as an audited Action.
• Filter the activity feed and read failure detail inline.
• (Platform admin) watch the cross-org failure console and acknowledge failures.
• Get in-app and email notifications, and tune them per Action type.