Use case
Track publications and rollbacks without a chat channel
A publication is a sequence of project outcomes, not just a green or red chat message. One structured inbox keeps the revision, environment, health result and recovery path available to people and agents.
Updated 6 min read
Use one event per meaningful outcome
- Record publication success only after the defined health checks pass.
- Record publication failure with the stage and immutable revision.
- Record rollback completion as a separate event linked to the same release context.
A deterministic deduplication key keeps retries quiet while distinct result types remain visible. The release identifier in metadata lets you correlate them without flattening the sequence into one mutable message.
Link to evidence, not hidden execution
Open the release
Provide an HTTPS link to the deployment record or commit view.
Review health evidence
Keep the summarized result in the event and detailed logs in their owning system.
Frequently asked questions
- Does the producer need a special integration?
- No. The examples use an authenticated HTTPS request, so any script, service or visual workflow that can send HTTP can use the same contract.
- Should credentials be included in notification data?
- No. Keep credentials in the producer's secret store and send only the context needed to understand or locate the event.
- Why send this to FYInbox instead of chat or email?
- FYInbox gives project notifications one structured, reviewable home instead of scattering them through Slack, Telegram and email. Those tools remain useful for conversations and intentional messages.
- Why structure notifications for people and agents?
- People and agents both need stable source, outcome and next-action context. FYInbox keeps that context in one notification record outside conversation streams.
Keep exploring
Put project notifications in their own inbox
Create an account and move the next notification out of chat and into one inbox for people and agents.