Based on the knowledge sources, there are several approaches to reset Elementary alert models if they've become corrupted: ### Option 1: Run Elementary models with full refresh You can run a full refresh on the Elementary schema if you don't need to preserve historical data:

dbt run -s elementary --vars '{"elementary_full_refresh": "true"}'

This will recreate all the Elementary models, including those needed for alerts [Slack forum discussion](https://slack.com/archives/C02CTC89LAX/p1681384521227129). ### Option 2: Drop and recreate the models If the full refresh doesn't work due to permission issues, you can: 1. Drop the Elementary schema 2. Run

dbt run -s elementary

to recreate all Elementary models from scratch This approach is mentioned in several support threads as an effective solution [Slack forum discussion](https://slack.com/archives/C02CTC89LAX/p1681384521227129). ### Option 3: Fix specific alert tables If you know which specific alert tables are corrupted, you can fix them directly. For example, if you have type mismatches in the

alerts_models

table:

CREATE OR REPLACE TABLE elementary.alerts_models AS SELECT * EXCEPT(detected_at), TO_TIMESTAMP(detected_at) as detected_at FROM elementary.alerts_models

This approach was used to fix timestamp type issues [Slack forum discussion](https://slack.com/archives/C02CTC89LAX/p1701705697028709). ### Option 4: Remove materialization overrides If you've overridden materializations in your

dbt_project.yml

, this could cause issues with Elementary alert models. Remove any global materialization settings and run:

dbt run -s elementary

This ensures Elementary views are created with the correct materialization [Slack forum discussion](https://slack.com/archives/C02CTC89LAX/p1681468420704779). After resetting the models, you should run your tests and then

edr monitor

to ensure alerts are working properly. I'm happy to provide more specific guidance if you can share details about the specific corruption issue you're experiencing.