> AI agents: this is one page from Mammoth Analytics documentation. The index of all pages as Markdown is https://docs.mammoth.io/llms.txt. Append `.md` to any docs URL, or send `Accept: text/markdown`, to get Markdown.

# Performance issues

> Diagnose slow Mammoth pipelines, dashboards, exports, and scheduled automations, and fix large-dataset and over-broad schedule problems.

Performance problems in Mammoth almost always trace back to one of three root causes: large unfiltered datasets being queried inefficiently, pipeline steps that process more data than necessary, or over-broad scheduled automations. This guide helps you identify the source and fix it.

## Quick diagnostic: What's slow?

| Symptom | Most likely cause | Go to |
| --- | --- | --- |
| Dashboard takes a long time to load | Source View is too large or unoptimized | [Slow dashboard loading](#slow-dashboard-loading) |
| Pipeline times out or runs for a long time | Large dataset + expensive operations | [Slow pipelines](#slow-transformation-pipelines) |
| Scheduled refresh takes hours | Too many datasets refreshing simultaneously | [Automation performance](#automation-and-scheduled-refresh-performance) |
| AI dashboard generation is slow | Wide Views or a complex prompt | [AI generation timing](#ai-dashboard-generation-timing) |
| Export to BigQuery or SFTP is slow | Export volume or destination configuration | [Slow exports](#slow-exports) |

## Slow dashboard loading

### Understand what makes dashboards slow

Dashboards load data by querying the underlying View at render time. The dashboard rendering itself is fast—the bottleneck is almost always the View query.

**What makes a View query slow:**

- The View is connected to a large dataset (millions of rows) without aggregation
- The View applies complex multi-step pipelines that run at query time
- Multiple charts on the dashboard each trigger separate View queries

### Step 1: Check view row count

1. Open the source dataset in your project
2. Navigate to the View your dashboard uses
3. Note the row count shown at the bottom of the View

The more rows the View holds, the longer each chart query takes. Views with millions of rows and no aggregation are the most likely to be slow.

### Step 2: Aggregate before the view

For dashboards showing KPIs, totals, and summary charts, the View should contain **aggregated data**, not row-level records.

**Pattern:** Add a **Group & Pivot** task at the end of your pipeline that summarizes data to the grain your dashboard needs. If your dashboard shows monthly revenue by region, the View should have one row per month-region combination—not one row per transaction.

### Step 3: Pre-filter the view

Add a **Conditional Filter** task to the pipeline before creating the View, limiting data to the time window or subset relevant to your dashboard.

Example: If your dashboard shows the last 12 months of sales, add a date filter to the pipeline so the View only contains the last 12 months—not all historical records.

### Step 4: Limit chart count per dashboard

Each chart on a dashboard triggers a query against the View. A dashboard with 20 charts on a 500,000-row View will load noticeably slower than one with 6 charts on the same View.

**Recommendation:** Break large dashboards into multiple focused dashboards (e.g., "Revenue Overview" and "Product Performance") rather than building a single all-in-one dashboard. This also improves readability.

## Slow transformation pipelines

### Identify the slow step

Use **Preview Data at this Task** on each task in your pipeline to see the row count at that point, and look for:

- Tasks where row counts are unexpectedly high (a filter that should reduce rows but doesn't)
- Tasks that work across the whole dataset (joins and group & pivot on large datasets)
- Math Function columns with complex calculations applied across millions of rows

### Fix the slow step

Once you know which step is slow, apply the matching technique from the [Performance guide](https://docs.mammoth.io/learn/performance/):

- Row counts that stay high: move **Conditional Filter** tasks as early as possible, ideally right after the data source
- A slow Join: check whether **Lookup** is enough, and whether the join key has duplicates
- Many unused columns: add a **Remove Column** task right after the source
- Heavy rebuilds while you edit: turn on Draft mode

See [Pipeline optimization](https://docs.mammoth.io/learn/performance/pipeline-optimization) for the full guidance on ordering tasks.

## Automation and scheduled refresh performance

### Understanding automation scheduling

How often an automation can run depends on your plan, and the units you can choose are listed in the schedule editor. If your workflow needs more frequent refreshes than your plan allows, contact [support@mammoth.io](mailto:support@mammoth.io) to discuss options. See [Scheduling](https://docs.mammoth.io/learn/automations/scheduling) for the frequency options and plan limits.

### Staggering scheduled refreshes

If multiple large datasets are scheduled to refresh simultaneously (e.g., all at midnight), they can compete for resources and each may run slower. Stagger refresh times between large datasets.

**To change an automation schedule:**

1. Open the **Automations** tab in the Data Library
2. Find the automation and open it
3. Edit the schedule
4. Save the automation

### Automation taking longer than expected

If a scheduled automation is taking significantly longer than previous runs:

1. **Check if the source dataset has grown significantly.** A much larger dataset takes longer to refresh.
2. **Check for downstream pipeline complexity.** If the pipeline was edited recently, a new task may be processing the full dataset in a slow way.
3. **Check whether other automations are running simultaneously** and competing for resources (see staggering above).

> **Reminder:** If an automation fails, open it, read **Last run result**, and fix the root cause. Then use **Run now** to re-run it.

## AI dashboard generation timing

AI dashboard generation takes a short while, because the AI reads your View's schema and data before building charts.

If generation seems stuck:

1. Refresh the page and try again
2. If it keeps happening, simplify the prompt and reduce the number of columns in the source View. Narrow Views with a few focused columns generate faster than wide Views with many columns

## Slow exports

### Export to cloud destinations (BigQuery, SFTP)

Export speed depends on:

- **Volume being exported**—large datasets with millions of rows take longer
- **Network throughput** between Mammoth and the destination
- **Destination write throughput**—some cloud warehouse configurations have write limits

**To improve export performance:**

- Filter the dataset before exporting—only export the rows the destination actually needs
- For incremental data, add a date filter to export only new or changed rows since the last export, rather than full table refreshes
- For SFTP destinations, verify that the SFTP server is not the bottleneck (check server capacity and available disk space)

## Large datasets

For guidance by dataset size, see [Dataset size guidance](https://docs.mammoth.io/learn/performance/#dataset-size-guidance) in the Performance guide.

## Still not resolved?

If you've applied these optimizations and performance is still unacceptable:

1. Check **Monitor**: the Running tab shows whether a task is **Stuck**, and Needs Attention lists failed runs.
2. Review Join steps—check whether the join key has duplicates (fan-out multiplies rows significantly).
3. Contact [support@mammoth.io](mailto:support@mammoth.io) with:
   - Your workspace name and dataset name
   - The pipeline ID, so the support team can inspect server-side execution logs
   - Approximate row count and column count
   - The specific operation that's slow (dashboard load, pipeline run, export, automation)
   - How long the operation takes vs. how long you'd expect

---
Source: https://docs.mammoth.io/learn/troubleshooting/performance-issues.md · Updated: 2026-10-13