Skip to main content
Monitoring is still behind a feature flag and is not available on every workspace yet. If you don’t see the View monitoring button, it is not enabled on your workspace.
Once your app is installed in other workspaces, you need to know when it breaks. Twenty records what happens to your app on the platform and shows it in two places:
  • The monitoring page of your app registration, for you as the app owner, aggregated across every install.
  • The workspace logs, for the admins of each workspace that installed your app, limited to their own workspace.

​
Open the monitoring page

Go to Settings → Developers → Apps, open your app, then click View monitoring in the General tab. You need the API keys & webhooks permission in the workspace that owns the app registration. Pick a period in the header: last 2 hours, 24 hours, 7 days, 30 days or 90 days. Data is kept for 90 days. Without the Audit logs entitlement, only the last 2 hours are visible.

​
What the page shows

Counts are exact: every rejected request and every skipped job is counted, even when the logs below only keep one row per minute.

​
What gets recorded

Every event below is counted on the monitoring page. Each one also writes app logs in the workspace where it happened, with a source that says where it came from: Rate limit and server route failures can repeat many times a second, so the logs keep one row per minute for each install, function and error code. The monitoring page still counts every occurrence.

​
Workspace logs

Admins of a workspace that installed your app see the same events, for their workspace only, in Settings → General → Logs. They can filter by source, for example to list only INSTALL failures or rate limits. Point your users there when they report a problem: the error code and message tell you where to look. For your own development server, twenty app logs streams function logs live in the terminal. See CLI.

​
Reading the signals

  • Errors climb right after a release: compare versions in the Versions table, then fix and publish a higher version. See Publishing.
  • API requests are rate limited: your app calls the API too often. Batch reads and writes, and avoid calling the API in tight loops.
  • Jobs are rate limited: database event or cron triggers fire faster than jobs can be enqueued. Narrow the trigger, for example with updatedFields on a databaseEvent trigger, or do the work in fewer, larger runs. See Logic functions.
  • Install or upgrade failures: check your install hooks. The error message is recorded with the failure.
  • Slow functions: a high 95th percentile duration points to a function worth profiling or splitting.