Health and Activity
See what went wrong in your application in the last day, ask the AI why, and read the record of everything that has happened to it.
Two tabs in your application's Settings tell you how it is doing and what has happened to it. Health shows what went wrong in the last day, and lets you ask why. Activity is the record of who did what, and when.
Everyone on your account can open both tabs.
Health: how your application is doing
Open your application, then Settings, then Health. The page covers the last day.
Health, the last day
The first line says when your application last reported its numbers, for example "Production last reported 4 minutes ago." If nothing has been released yet, it says figures appear after the next release. If some numbers were not reported, it says so, so you know the figures are low rather than reassuring.
The figures
There is one section for production, and one for each test copy that reports. Each shows:
| Figure | What it means |
|---|---|
| Requests measured | How many requests the application handled |
| Failed | The share of requests that failed or stopped part-way, and how many |
| Refused | Requests a rule said no to, such as a permission. Usually this is your application doing its job |
| Slowest 5% | How long the slowest requests took, in milliseconds |
| Unhandled errors | Errors the application did not expect |
Nothing is shown as nought unless it was measured as nought.
What went wrong
Under the figures, What went wrong lists each kind of failure, refusal or unexpected error, the most frequent first, with how many times it happened and the version it started in. If there were none, it says "Nothing failed, was refused or threw in the last day."
Below that, The slowest screens and actions lists the pages and actions that took longest, once they have had enough requests to judge.
Ask why something went wrong
Beside each item in What went wrong you can ask the AI what is most likely causing it.
- Optionally, type what you or your staff noticed in What did you see? (optional), for example "the booking page showed an error after we added a service".
- Press Ask why.
The answer appears at the top of the page and is kept under Diagnoses. It says what is most likely at fault (your application, the Divvent platform, a connected service or the hosting provider), how confident it is, and why. Then one of these:
- fix proposed: the AI has suggested a change to your application. It comes with a worked example that fails against the application as it is and passes with the fix. It is a change like any other, waiting for review; press Read the change to open it. Nothing changes until it is approved and released. See Read a change and approve it.
- ours to fix: the same fault is happening in other applications, so it is in the platform and our team fixes it. No change to your application is suggested.
- fix not carried: a fix was suggested but did not pass the checks, so it is not offered. The reasons are listed.
- nothing to change: no change to your application would help.
- the provider's: the problem is with the hosting provider or a connected service.
What it costs, and what it reads
- It spends your account's AI budget, the same budget that pays for proposing changes. See Plans and billing.
- Asking again within the hour is free. If the same problem was diagnosed in the last hour, you get that answer again, marked "This was diagnosed within the hour; here is that answer."
- Each person can ask up to 20 times an hour.
- It reads numbers, not records. The AI is given counts, the kind of error, timings and which version was running, plus anything you typed in the box. It is never given your application's records. See The AI and your data.
Ask why appears only to people whose role can ask for changes: editors, admins and owners.
Incidents
Divvent watches your application's numbers every hour, counts and codes only, and looks into anything unusual before you need to. The Incidents section on the Health tab lists what it found, whether it is open or resolved, and whose it most likely is. If our hosting provider had a problem, it says so, and that it was not caused by your application or your changes.
Owners and admins can choose when your account is emailed about an incident, after it is over, with Tell this account about an incident, after it is over:
- only when it reached our users (the starting setting): when failed or refused requests reached production.
- every time.
- never.
Press Save. The emails go to your account's owners. Status and incidents explains what else you are told, and when.
Activity: who did what, and when
Open your application, then Settings, then Activity. It lists everything that has happened to the application, newest first, in four columns:
- When it happened.
- Who did it: a person on your account, by their email address, or Divvent for anything done by our team or by the platform itself. Someone who has since left the account shows as "someone no longer on the account".
- What happened, in words: "Asked for a change", "Approved the change", "Released the change", "Rolled back", "Added a domain", "Started an export" and so on.
- About: what it was done to. A change links to its page, and a release links to Releases.
You can filter and sort the list, and it shows 25 entries a page. It holds the most recent two hundred entries; if there are more, the page says so.
Support access in Activity
If our team ever needs support access to your application, it is recorded here: when it was asked for, when it was approved, each reading made under it, and whether it was ended early. Your owners are also emailed when it is approved. See Security, and what Divvent can and can't see.