Monitoring

Monitoring is a very important part of flag management, it lets you track real-time usage of your flags and helps you answer questions such as:

  • Is this flag still used?
  • How many users are seeing the new feature?
  • Which services are using this flag?
  • When was this feature released exactly?

To view the monitoring data, click on the Monitoring tab in the flag details page:

Monitoring tab

How far back can I see the monitoring data?

Depending on you plan, you can see the monitoring data as far as 1 year in the past and a granularity as low as 1 minute intervals.

Monitoring granularity

How is usage tracked?

If you are using one of our Javascript or PHP SDK, you do not have to do anything, we automatically track usage for you. If you implemented you own client, you will need to track usage manually by following the specifications.

How many users saw a feature?

You can hover the variations graph to see exactly how many users saw each variation at any given time. This lets you track the rollout phase over an extended period of time.

Variations graph

If your flag has more than 2 variations, or some variations have since been deleted, you can still see all the historical data here.

Which service or app is using my flag?

You can hover the evaluations graph to see which service or app is evaluating the flag at any given time. When reporting data back to Tggl, each client identifies itsel. You can leverage that information to know which version of which app has evaluated the flag.

Monitoring clients

How to know if a flag is still being used?

When you remove a flag from you codebase and deploy the change, you will see a drop in the evaluations graph. This is a good way to know if a flag is still being used or not.

Monitoring drop

Using monitoring to reduce technical debt

Monitoring is a very powerful tool to reduce technical debt. It lets you know exactly when a feature was released, when it was last used, and how many users are still using it. This information can help you make informed decisions about removing old code, and reducing the complexity of your codebase.

You may want to read the next chapter dedicated to technical debt.