What the bar and the row are telling you, what stops while a login is expired, and how to start collecting and delivering again.
What you are looking at
The bar at the top of the page does not name a destination that stopped because its login expired. That fault is on the Destinations page only, so the bar going quiet is not proof that everything is repaired.
The repair itself is on a row: on Sources, where feedback is collected from, or on Destinations, where findings are delivered. Each row carries a badge, and the badge names the fault.
Which fault you have
One tool name can sit on several rows at once. Slack can be a source, a destination, and the private channel a colleague is reached on, and each of those has a different repair. The badge tells you which one you have, so open Sources and Destinations and read the badge on every row for that tool.
Login expired, on a source row or a destination row: the tool's sign-in no longer works. This is the fault you repair, and the steps are below.
Delivery failing, on a destination row: findings are not arriving there. Send a test delivery, in the steps below. A destination whose login expired reads this too, and the login has to be reconnected first.
Can't read #run-day, on a source row: one channel, group or inbox cannot be read, and the login is fine. Usually the @echoux app was removed from it. Invite it back in the tool, and collecting starts again with no further act from you. With more than one, the badge reads Can't read 2 channels.
Collection failing, on a source row: repeated errors reading that source, with no cause named. It is retried automatically and there is nothing for you to do.
Can't connect, on either row: an echoUX-side fault, not your login, so the row offers no Reconnect. Open the row and its own sentence says what to expect.
What stops while the login is expired
The sources on that login stop collecting. Every other source keeps collecting, and every destination that is working keeps receiving findings, the discovery artefacts delivered to your tools.
When delivery keeps failing, the destination is marked Delivery failing. Findings made after that point are never delivered there, and repairing the destination does not bring them back. The findings themselves are kept, and every other destination on the topic still receives them.
A person reached on a private Slack channel in that workspace stops receiving notices there. They still receive email, and a notice about your account reaches them by email even when their email switch is off.
What to do
A login that expired
Open Sources, or Destinations for a destination, and select the row that reads Login expired.
Select Reconnect. Signing in to the tool again is in Reconnect a tool.
Open Destinations and read every row on that tool. Reconnecting clears both ends of that connection, so a destination that reached Delivery failing while the login was expired carries no badge either.
A destination that still reads Delivery failing
Deliveries can also stop for a reason that has nothing to do with a login, when the receiving service refuses them. An expired login puts no line about this on the bar, so read the rows.
Open Destinations and select the row that reads Delivery failing.
Select Test delivery.
When the test arrives, the row shows Delivered, and new findings are delivered there again.
When the test fails, the row shows Failed. Select Show details for the reason, repair it, then select Retry test delivery.
The fix has worked when
- the row on Sources or Destinations carries no badge;
- no destination on that tool reads Delivery failing;
- the bar's line is not there when you next open a page.
What happens next
Collecting starts again at the next cycle, the next pass over a batch of feedback. It starts from the point it stopped, as far back as the tool still holds that history. Deliveries that were still waiting are tried again.