Test results in Slack, with enough detail to act on
A failed automation test, a dropped device session or a finished accessibility scan arrives as a formatted card carrying the device, the duration, the reason and a link straight back to the run.
Paste an incoming webhook URL · no Slack app to install
🔴 Automate test failed — Checkout suite
Open session →
- No Slack app
- paste an incoming webhook URL
- Failures-only preset
- or every result, per product
- Reader's-clock times
- the one thing only Slack renders
- 5 retries
- before a delivery is marked exhausted
What actually lands in the channel
Every message is a Block Kit card built from one neutral description of what happened.
A severity you can scan past
The header carries an emoji chosen by severity — a tick for a pass, a red circle for a failure — so a reader scrolling by decides whether to stop.
The facts, not a status word
The build or test name, the product and the device it ran on, who started it, when, how long it took, and a plain-English reason when a session ended for one.
Times in the reader's timezone
The start time is sent as Slack's date token, so a tester in Delhi and a lead in Berlin each see it on their own clock. Only Slack of the four channels can do this.
No 'N/A' clutter
A fact with no value is dropped rather than printed as N/A — device sessions have no project, so that line simply doesn't appear.
A link straight back to the run
The last line opens the session or scan, where the recording, console output and network log for that test are waiting.
Reliable delivery
The webhook URL is re-validated before every dispatch, redirects are refused, and a slow channel never holds up the test that triggered it.
Every event you can subscribe to
Pick events per product — by hand, or with a preset (all results, or failures only). These are the only events that exist.
Device farm & accessibility
- Automate test passed, failed or errored
- Live session ended (neutral) or failed
- Accessibility scan completed or failed
Test management
- Test case created or deleted
- Cycle created, completed or deleted
- Plan created, completed or deleted
- Bulk execution completed
Deliberately absent
- Visual — appears in the picker with an empty list; nothing emits a visual event yet.
- No automate.build.completed — a build is a label, not an object with a lifecycle.
- Attempts before a delivery is marked exhausted
- 5
- After which an incomplete send is abandoned
- 10s
- Delivered records are swept after a week
- 7 days
- Unsuccessful records are swept after a month
- 30 days
Sending is fire-and-forget — a slow channel never holds up the run. Retries are spaced a minute, five minutes, half an hour, two hours and eight hours apart. Loopback, private, link-local and multicast addresses are refused, and redirects are not followed. The same rules cover a raw JSON webhook.
Frequently asked questions
No. You create an incoming webhook in Slack, paste the URL into TestKase, name the integration and choose its events. There is no OAuth flow and no bot user, and the traffic only ever goes one way — out of TestKase, into your channel.
No. One integration is one webhook URL, which means one channel. For failures in one channel and accessibility scans in another, create two integrations with two URLs and give each its own event list.
Take the failures-only preset for a product instead of all results, and leave the test-management events off unless somebody wants them. A Live session ending is deliberately neutral rather than a success — a tick on every closed session is the noise that gets an integration muted.
The message is retried up to five attempts, spaced a minute, five minutes, half an hour, two hours and eight hours apart, then marked exhausted. If you switch the integration off part way through, the pending delivery is cancelled rather than retried.
No. An incoming webhook carries no images and no interactive elements — the card is text and a link back to the run, where the recording, logs and screenshots live. Filing a defect into your tracker happens inside the product.
Not yet. Visual is in the event picker with a deliberately empty list: nothing emits a visual notification event today, and offering a subscription to a message that never arrives would be worse than admitting the gap.
Put the next failure in the channel that will read it
Create a webhook, choose failures only, and see what the first real card looks like.