Link a status page component to a system
Some outages aren’t yours — they belong to a provider you depend on, like your email sending service. Atender runs a dependency watcher that checks the health of those providers once a minute. When you link a status page component to the matching system key, that watcher can open the incident and update your status page for you, without anyone on your team touching a keyboard.
Before you start
You need a component that represents the dependency on your status page — for example, a component named “Email delivery.” If you haven’t created one yet, see Create an incident for the surrounding workflow, or add the component from the Components tab first.
Link the component
- Go to Incidents → Components.
- Open the component you want to link (or create a new one).
- In the component’s settings form, find the System link field.
- Choose the system key that matches the dependency — for example, Email.
- Save.
Once saved, the component shows a Linked: Email badge in the components list, so your team can see at a glance which components are wired up to automated monitoring.
Leave System link set to None for any component you want to manage manually — nothing changes for it; you still create and update incidents for it yourself.
What happens once it’s linked
Atender’s dependency watcher runs continuously in the background. For a linked provider, it evaluates two independent signals:
- Internal error logs — a spike in provider-side send failures recorded by Atender itself.
- The provider’s own public status feed — in case the failure never shows up in your logs at all (an inbound-only fault, for instance, never touches your send path).
Either signal on its own can miss a real outage, so the watcher trusts whichever one fires first.
When the watcher confirms an outage for a system key that’s linked on your tenant:
- The linked component is automatically marked degraded (or the appropriate outage status) on your public status page.
- An incident is opened for it, visible to your subscribers and to your AI/human agents the same way any other incident is.
- A message is posted to Atender’s internal Slack channel naming the affected dependency.
Recovery is never assumed on a timer. The incident clears — component reset, status page updated, a follow-up Slack message posted — only once the watcher has real evidence of recovery: a genuine successful transaction after the incident opened (for the log signal), or the provider’s status feed reporting nothing unresolved (for the feed signal). Until one of those is true, the incident stays open even if things look fine again.
Constraints to keep in mind
- One component per system, per tenant. You can link at most one status page component to a given system key (e.g. only one component can carry the Email link). If you need to reassign the link, set the currently-linked component back to None first, then link the new one.
- Unlinked means invisible. If a component’s System link is None — either because you never set it or you removed it — an outage in that dependency won’t be reflected on your status page or trigger anything automatically for that tenant. The watcher still posts to the internal Slack channel regardless, since that alert isn’t tenant-scoped, but your customers won’t see anything unless you create the incident yourself.
- Automated incidents behave like any other incident once opened — they show up in your incident history, count toward your status page timeline, and are visible to Sidekick and your Agent Stacks the same way a manually-created incident is.