First 30 Days with MetricSign: Onboarding Guide

Sign up at app.metricsign.com — no credit card required. The onboarding flow walks you through connecting your first integration immediately after account creation.

Which connector to start with: choose the tool that causes the most pain right now. For most teams that is Power BI (scheduled dataset refreshes) or Azure Data Factory (pipeline runs). If you already know you have Tableau extract issues, start there.

The connection flow: 1. Select your connector from the list (Power BI, Tableau Cloud, ADF, Snowflake, dbt Cloud, dbt Core, Databricks, Apache Airflow, Qlik Cloud, or Microsoft Fabric). 2. Click Connect — MetricSign redirects you through an OAuth flow or prompts for a Personal Access Token depending on the connector. 3. Grant read-only access. MetricSign never requests write permissions. 4. Return to the dashboard. MetricSign imports the past 7 days of job history in the background.

What you see immediately: within a few minutes the Incidents tab populates with any failures from the past week. The Overview tab shows the status of every monitored pipeline — green for healthy, amber for delayed, red for failed. If nothing is broken right now, that is useful information too: you have a baseline.

The incident feed is the main working surface in MetricSign. Each entry represents a single event — a failed refresh, a delayed pipeline, a flow error — with enough detail to act on immediately without logging into the source system.

Incident types you will see: - Failed refresh — a scheduled or manual refresh completed with an error. The incident includes the error message from the source tool. - Delayed refresh — a refresh has not completed within its expected window. MetricSign detects this before the refresh actually fails, giving you a warning before stakeholders notice stale data. - Pipeline failure — an ADF pipeline, dbt run, Airflow DAG, or similar job finished with a non-success status. - Stale data — a published dataset or workbook has not been refreshed within a configurable freshness threshold.

Reading the incident detail view: click any incident to open the detail panel. You will see the timeline of events (when the issue started, when it was detected, whether it has recovered), the affected asset (dataset name, pipeline name, workspace or project), the raw error message, and — if cross-stack lineage is available — any linked upstream incidents.

Closing an incident: once you have investigated and the underlying issue is resolved, mark the incident as resolved. MetricSign will continue monitoring and open a new incident if the same failure recurs.

Checking the dashboard manually defeats the purpose of monitoring. The goal is to receive a notification the moment something breaks, so you can act before stakeholders notice. Set up alerts in the first week.

Connect Slack or Microsoft Teams: 1. Go to Settings → Alert Channels. 2. Click Add Channel and choose Slack or Teams. 3. Paste your incoming webhook URL. (In Slack: Apps → Incoming Webhooks. In Teams: channel connector settings.) 4. Send a test notification to confirm it works.

Choose which incident types trigger alerts: you probably want alerts for all failed refreshes and all pipeline failures. You may want to suppress delay alerts outside business hours if your pipelines run overnight and the team cannot action them until morning.

Business-hours filtering: the alert channel settings include a schedule option. Set active hours to your team's working hours and MetricSign will hold delay and stale-data alerts until the window opens. Critical failures (complete failures, not just delays) can bypass this filter if needed.

Add team members: Settings → Team. Add colleagues by email address. Each person can configure their own notification preferences independently — some people want all alerts, others only want alerts for specific connectors or workspaces.

By the end of week one you have a working alert channel and a week's worth of incident history from your first connector. Week two is the right time to connect a second tool.

Why add a second connector: MetricSign's cross-stack lineage only activates when two or more connectors share data dependencies. The most common pairing that unlocks lineage immediately is: - Power BI + Azure Data Factory — ADF pipelines that load data to Power BI datasets - Power BI + dbt Cloud — dbt models that feed Power BI datasets - Tableau Cloud + Snowflake — Snowflake queries behind Tableau extract refreshes

What cross-stack lineage looks like: once MetricSign detects a dependency between a dbt model and a Power BI dataset, it links them in the asset graph. When the dbt model fails, you see the Power BI incident flagged as a downstream consequence — not a separate unrelated failure. The incident detail view shows the chain: dbt model failure (02:14) → Power BI dataset refresh failed (02:31) → 3 reports affected.

Adding a connector: Connectors → Add Connector. The flow is identical to the first connector. MetricSign will begin importing history for the new tool and immediately start correlating events across your connected stack.

After two to three weeks of data, patterns emerge that you cannot see from individual incidents. The Overview and Analytics tabs become genuinely useful at this point.

What to look for: - Which datasets refresh slowest — the Refresh Duration trend shows whether a dataset is taking longer to refresh over time. A dataset that used to refresh in 4 minutes and now takes 12 minutes is a capacity problem in the making. - Which pipelines fail most often — sort the Incidents tab by asset name to see which pipelines generate the most incidents. The top three are usually candidates for architectural fixes, not just monitoring. - What time of day incidents peak — most teams discover that their overnight batch windows have a consistent failure spike at a specific time. This often points to a resource contention issue (too many jobs scheduled at once) rather than individual pipeline bugs. - Recovery time — the average time between incident opened and incident resolved. This is your current mean-time-to-detect plus mean-time-to-resolve. Your goal is to reduce the detect part to near-zero by keeping alerts active.

Use these findings to prioritise fixes. A pipeline that fails once a week for 30 seconds is lower priority than one that is delayed by 90 minutes every Tuesday morning when stakeholders need it.

By day 30, a typical MetricSign team has:

• Connected 2–4 integrations — enough to cover their primary data stack and activate cross-stack lineage.
• Caught 3–5 incidents they would have missed — incidents that would have surfaced only when a stakeholder reported stale data or a broken report.
• Reduced mean-time-to-detect from hours to minutes — the most common feedback is that teams used to find out about failures 2–4 hours after they occurred (when someone checked a report). With MetricSign alerts, the team knows within minutes.
• Established a reliability baseline — failure rates, refresh durations, and peak incident times documented well enough to inform the next quarter's infrastructure decisions.

Can I add more connectors later? Yes. All 10 connectors are available on every plan at no extra cost. You can connect additional tools at any time from the Connectors page. There is no limit on the number of connectors or workspaces per organisation.

Do I need to give MetricSign write access? No. MetricSign uses read-only API access for all connectors. It reads job history, run status, and metadata. It does not trigger refreshes, modify pipelines, or write to any of your connected tools.

What if I have multiple Power BI tenants? MetricSign supports multiple workspaces within a single Power BI tenant. If you need to monitor multiple tenants (separate Microsoft Entra directories), contact support — multi-tenant configurations are available on request.

What does the 45-day trial include? The full product — all connectors, all alert channels, unlimited team members, and all analytics features. No feature gates, no sandbox mode. If you connect a real environment, you see real data.