Demo
One incident, end to end.
This is a walkthrough, not a sandbox you can sign into: the panels below belong to a fictional meal-planning product called Mealtime, and every number in them is made up. What is not made up is the order — this is the sequence ErrorDock puts an incident in front of you in, from "something changed" to "this is the one to fix first".
Illustrative walkthrough. Contact us about beta access.
Step one
Release 3.1.2 went out on Tuesday.
Usage is flat. Errors are not. Feature health shows where: one feature's error rate has jumped since the release, while every other feature is flat.
Mealtime
Last 14 days
Active users
26,104
+1.1%increase, improvingSessions
61,882
+0.4%increase, improvingErrors
4,207
+312%increase, worseningAffected users
2,144
+286%increase, worseningFeature health · Recipe Import
8.4%
Error rate, up from 1.0% before 3.1.2. Every other feature is flat.
Events per day
Recent issues
Ranked by impact
TaskCanceledExceptionRegression
RecipeImportClient.cs:74v3.1.2
JsonException
NutritionParser.cs:212v3.1.2
InvalidOperationException
ShoppingListBuilder.cs:38v3.0.9
The top issue is a regression. It was resolved in 3.0.4 and came back in 3.1.2, so ErrorDock reopened it rather than filing it as new — which is the difference between "unknown bug" and "the fix did not hold".
Step two
The exception, with what led to it.
The stack trace is resolved to your source and your own frames are marked, so the four lines that belong to you are not buried in forty that belong to the framework.
Underneath it, the breadcrumb trail. The user opened the import screen, the application called the nutrition provider, and thirty seconds later the request was cancelled. That is not a stack trace's story to tell — but it is the one that explains the bug.
How error monitoring worksIssue detail
TaskCanceledException
TaskCanceledException
A task was canceled.
Events
3,918
Affected users
2,061
Introduced
v3.1.2
Environment
production
Stack trace
Breadcrumbs
- 30s ago POST /api/recipes/import — 500
- 30s ago HTTP GET nutrition.example/v2/lookup — timeout
- 60s ago User clicked "Import recipe"
- 2m ago GET /recipes/new — 200
POST /api/recipes/import
Slowest transaction, last 24 hours
P95 response time
31.4 sec
since release 3.1.2
Trace
One outbound call, thirty seconds of it. The nutrition provider stopped responding and the client waits out its 30-second timeout, so every import holds a request open for half a minute before failing. The exception in step two is this timeout arriving.
Step three
Where the time actually went.
A P95 of thirty-one seconds tells you the endpoint is slow. The waterfall tells you which operation inside it is slow, which is the only version of that sentence you can act on.
Here it is a single outbound call parked on a 30-second timeout — a small fix, once you can see it. Without the trace, the same investigation starts with reading the import code.
How performance monitoring worksStep four
And how many people depend on it.
Recipe Import is the second most used feature in Mealtime: 41.2 percent of active users touched it in the last ninety days. That is the number that turns a broken endpoint into a priority.
Note the bottom row for contrast. Meal Sharing throws errors too — at a higher rate — and it does not matter, because eleven people have used it since June. Ranking by event count would put it above the import.
Feature adoption
Last 90 days
| Feature | Users | Adoption |
|---|---|---|
| Meal Planner | 14201 | |
| Recipe Import | 10753 | |
| Shopping List | 9884 | |
| Nutrition Report | 2610 | |
| Meal SharingUnderused | 11 |
Recipe Import — weekly users
10,753
+2.4%increase, improvingPriorities
Ranked first
Recipe Import · TaskCanceledException
#1
Top of the list since 3.1.2
Adoption
41.2%
Affected users
2,061
+286%increase, worseningError rate
8.4%
+740%increase, worseningP95
31.4 s
+1940%increase, worseningWhy this ranks first
TaskCanceledException in Recipe Import should be fixed before anything else in the list.
It affects 2,061 users in a feature 41.2% of your active users depend on, it is a regression of an issue resolved in 3.0.4, and the trace shows a single outbound call waiting out a 30-second timeout. In Priorities the row lists every input with its raw number, normalised share, weight and points, so the ranking can be checked rather than trusted — and the three signals sit in one project, which is why they can be read together.
Step five
Ask why, and then ask for a patch.
The analysis runs on your own model key and separates the symptom from the immediate failure from the root cause. The confidence score is ErrorDock's, computed from what could be checked — not the number the model reported about itself.
AI analysis
TaskCanceledException · Recipe Import
- Symptom
- TaskCanceledException in Mealtime.Import.RecipeImportService.FetchAsync
- Immediate failure
- HttpClient.SendAsync exceeded the client's 30-second timeout
- Root cause
- 3.1.2 replaced one batched catalogue call with one request per recipe, and the provider cannot answer them all inside the client's 30-second timeout
Confidence
81 / 100
Evidence verified
4 of 5
Suspect commit
a4f19c2
Files in patch
1
Validation
- Applies ✓
- Structure ✓
- Secrets ✓
- Second opinion ✓
- Build —
- Tests —
A dash is not a pass. ErrorDock does not run your test suite, and it says so on the row rather than leaving the stage out.
What happens next
Nothing, until an administrator presses the button.
Repository writing is not enabled in the current beta setup. When available, a pull request needs the installation switch, the organisation setting, the admin-only permission and an explicit confirmation — and immediately before the write, ErrorDock rechecks that the file has not moved. The commit is authored by ErrorDock and records who authorised it. Nothing is ever merged.
Now do that with your own errors.
Install the SDK, deploy, and see your first issue with a full stack trace and the users it affected.
No credit card required.