Connection troubleshooting

Live Connections can fail because of authentication changes, network problems, or source system updates. This guide covers failures in data import, data export, pipeline execution, and data addition. It is for anyone whose automation shows an Error status or whose refresh fails.

Understanding connection failures

Live Connections don't have a status you can check ahead of time. A connection's health is only revealed when a refresh actually runs and either succeeds or fails.

• Normal operation: OAuth-based connections proactively refresh their access token before it expires, so most connections keep working without any action from you.
• Authentication failure: If a credential is revoked, rotated at the source, or a token refresh fails, the next refresh for that connection fails with an authentication-specific error. Reconnecting the Live Connection is required. See Authentication failures.
• Other failures: Source-system downtime, network issues, and rate limiting surface as a generic runtime error. There is no separate "temporarily unavailable" state, and no automatic retry. See Connection failures during automation runs.

Common issues and how to resolve them

Authentication failures

Authentication failures occur on both the import side and the export side. These involve separate credentials and must be resolved independently.

Import authentication failures (PostgreSQL, MSSQL, and other source connectors)

When a Live Connection used for data import loses authentication—due to an expired token, a rotated password, or a revoked credential—the dataset refresh fails with an authentication-specific error. The automation shows an Error status; open it and check Last run result for the reason.

To resolve, reconnect the affected Live Connection, then run the automation again with Run now to confirm it works.

Export authentication failures (PostgreSQL, BigQuery, and other export destinations)

Export authentication failures occur when the write credentials for a destination have expired or been revoked. This is separate from a source connection failure—the export destination has its own credentials that must remain valid independently.

To resolve, update the export destination credentials in the export configuration. Use Validate Connection in the export form to confirm the credentials work before you apply the change, then re-run the export. If you are using a Mammoth managed PostgreSQL or BigQuery database, Mammoth manages authentication—contact support if you encounter failures on these destinations.

---

Pipeline errors

Pipeline errors occur when a transformation task fails during execution. These are the most common error types you'll encounter after a connection or schema change.

Column missing

A pipeline task references a column that no longer exists in the dataset. This typically happens when the source schema has changed—a column was renamed, removed, or its data type was modified upstream. Identify which task in the pipeline is referencing the missing column, update the task to reference the correct column, and re-run the pipeline.

Type change errors

A column's data type has changed at the source, causing downstream pipeline tasks that depend on that column's type to fail. Update the affected tasks to account for the new type, or add a type conversion step earlier in the pipeline before retrying.

Dependency errors

A pipeline task depends on another task or a secondary dataset that is in an error state. Tasks don't run if their dependencies have failed. Resolve the upstream error first, then re-run the pipeline.

Slow pipeline runs

This isn't a pipeline error as such—the pipeline still completes—but execution can take significantly longer than expected. This is typically caused by a large increase in data volume at the source, or a transformation task processing more rows than anticipated. Review which task in the pipeline is responsible for the slowdown, and consider adding filters to reduce the data volume being processed at that step. See Pipeline optimization for detailed guidance.

Schema mismatch and data addition failures

These errors occur when data being added to an existing dataset does not match the dataset's current structure.

Data addition failures (schema mismatch, type change, missing column)

When you add data to a dataset—through a dataset refresh, data consolidation, or a manual addition—Mammoth compares the incoming data with the existing schema. What happens to a missing, renamed, or retyped column depends on the dataset's If column type doesn't match and column mapping settings: Mammoth can convert the column to text, convert incompatible values to null, or leave the dataset unchanged. See Add or replace data. The error notification for a failed addition includes the failure reason and the affected dataset name.

To resolve a failed addition, reconcile the schema difference at the source so that the incoming data matches the dataset structure, or adjust the dataset's mapping settings, then retry the operation.

Send to Dataset column errors

When you use Send to Dataset to send processed data from one view to a destination dataset, the column mapping must align with the destination dataset's schema. If a mapped column no longer exists in either the source view or the destination dataset, the operation fails.

To resolve, review the Send to Dataset configuration, confirm all mapped columns exist in both the source view and the destination dataset, update the mapping, and retry.

Connection failures during automation runs

When a Dataset Refresh automation fails because of a connection issue, the automation shows an Error status, and Last run result in its detail panel gives the reason.

Mammoth does not automatically retry a failed run—this prevents cascading failures when the underlying issue is systemic. Fix the root cause, such as an expired credential, then trigger a run with Run now instead of waiting for the next scheduled run. If the automation is on a recurring schedule, it still runs at its next scheduled time regardless of the earlier failure, but that is the normal schedule continuing, not a retry of the failed run.

When a single automation refreshes several datasets, each connection is validated independently. Partial success is possible—some datasets may refresh successfully while others fail.

Network and firewall issues

If connections are failing intermittently and authentication is confirmed valid, the issue may be network-related. Confirm that your database or service accepts connections on its port and that the Mammoth IP address shown in the connection form is allowed in your firewall configuration.

Mammoth uses outbound HTTPS (port 443) for all service communications. Custom database ports are also supported: 1433 for SQL Server, 5432 for PostgreSQL, and 3306 for MySQL. SSH tunneling is available for secure enterprise database access (configurable per connector: proxy host/port and auth type). See Network requirements. If you need Mammoth's outbound IP ranges added to an allowlist, or need SSH tunnel access configured, contact support.

Rate limiting

If a source system limits how often it accepts requests, refreshes may fail until the limit resets, with no automatic retry for that run—the same as any other automation failure. The automation runs again at its next scheduled time, or you can run it with Run now once the limit has reset. To reduce rate limit exposure, review automation schedules to avoid concentrating many refresh operations on the same source at the same time, and consolidate datasets where possible.

What the Activity Log captures

The Activity Log records changes made in a workspace or project and is useful for audit, compliance, and governance. It captures events such as:

• Datasets, views, and other items being created, edited, renamed, or deleted
• Data being added to a dataset, datasets being combined or replaced, and datasets being duplicated
• Batches being suspended or un-suspended
• Pipeline tasks being added, edited, renamed, or removed, and views being re-run
• Connections being added, edited, or deleted
• Automations being edited or updated
• Retention policies and workspace membership changes, including users being invited to or removed from the workspace

The Activity Log records changes, not errors, and it does not record the health of a Live Connection. The error scenarios covered in this guide are not logged there. They are surfaced through in-app error indicators and, for some failure types, notifications. Check the automation's status and Last run result, and the error shown in the interface.

A note on webhook errors

Webhook data received via POST/GET request is a separate ingestion mechanism and is not covered in this guide. If you are experiencing errors with webhook ingestion, contact Mammoth support.

When to contact support

Contact Mammoth support when errors persist after following the steps in this guide, or when you need assistance with IP address allow rules, SSH tunnel configuration, or enterprise authentication setup.

When you contact support, include the connector type, the exact error message from the notification or error indicator, and a summary of the troubleshooting steps you've already tried.