We are excited to announce our latest product, iHook Receiver! A receiver provides an iHook hosted API endpoint to receive HTTP requests from external resources, and can send email/Slack notifications whenever those requests are triggered.
Receiver is a handy tool to accept webhooks from web services such as SendGrid and Okta, and notify you with the data of your interest. You can use JSON path expression to process and filter webhook request data that is sent to your receiver.
Free plan users can create up to 10 receivers. Each receiver comes with a 20 per minute rate limit for incoming requests. For more details about how to set up a receiver, please take a look at our quick start doc.
Notification status under Task History
We added the Notification Status section for each task execution detail under the history page. With this enhancement, users will have better knowledge about their notification condition evaluation results and notification delivery results for each task execution:
Task history loading performance improvement
We reduced the task execution items per page from 20 to 10. This will improve the task history page's loading speed, especially for tasks with larger response body.
Thank You
Thank you for reading! We look forward to your feedback about our latest product Receiver. Please feel free to contact us at support@ihook.us! Have a great weekend!
Happy New Year everyone! Hope you are all doing well. It's time for another product update.
New daily email usage limit
To prevent email service abuse, we updated the email quota for free plan accounts: 20 emails per 24-hour period.
When the email quota is reached, the related task will be disabled and an email notification will be sent to your primary email address that is provided during registration.
You may re-enable the task once your quota becomes available again - the sending limit is applied over a rolling 24-hour period, and your quota will be fully renewed after 24 hours. To help you monitor the usage, we rolled out a usage section on the account page, you can check it out here.
We feel like the new quota should be sufficient for regular use cases since too many emails sent during a short period would become noisy anyway. We’ll keep trying to understand our users' email usage patterns and iterate on the quota plan so that our free plan users don't get too annoyed by task disablement due to email overuse.
Task execution error reminder
One pain point of our users is that when their task notifications failed to deliver (e.g. due to misconfigured condition rule, or incorrect delivery email address), it's hard for them to notice the failure, since the task execution was marked as COMPLETED, and they have to expand the task execution detail, and look at the Errors section for any errors.
Now when such failure occurs, the task execution will be marked as FAILED, so it's easier for users to notice the failure without having to expand the execution detail.
On top of that, when a notification delivery failed due to a misconfigured notification condition 5 times in a row, the task will be disabled and an email notification will be sent to your primary email address. We think that a task with a misconfigured notification is incomplete, and disabling the task would help force users to correct their notification setup.
Task disable email notification enhancement
We enhanced the task disablement email notification. Now each email will show detail about the reason for the disablement, such as email/SMS usage exceeds the limit, invalid notification condition, or the HTTP task's response body exceed the limit. This will help users troubleshoot their task setup and help them fix the issue and re-enable the task faster.
New shortcuts
To make task editing experience more smooth, we now support using Esc key to cancel task edits. See here for a full list of shortcuts we supported.
Thank You
Thank you for reading! As always, if you have any feedback on our product and features, please contact us at support@ihook.us, we look forward to hearing from you! Happy New Year!
Happy Halloween! Although Halloween will be different than usual this year, I hope you enjoy the holiday with family and friends while staying safe. Here are the product updates for October.
Sorting options for task list
We added sorting support for the task list page. For the business plan, people can create dozens of tasks, and sometimes it's hard to find a task in the list since they are sorted by created date in descending order.
With the new sorting options, in addition to the current sort by created date option, you can sort by task name and last opened date. This will help you organize your tasks. For example, if you visit some tasks more frequently than other tasks to review the execution history, you may find sorting by Last opened at helpful.
Option to allow insecure server certificates
Before this change, iHook's requests to remote HTTP resources with invalid certificates would end up in FAIL state, with invalid certificate error shown in the task execution detail section under the History tab.
We added an advanced option under the Request Settings section to allow such requests to succeed. While it's a best practice to configure valid SSL certificates for production web resources, you may still need to issue requests to HTTP endpoints where a secure certificate is not readily available. In such cases, you may find this new setting helpful.
Schedule delay for interval-based tasks
When tasks are scheduled to execute in a fixed interval such as every 1 hour, each execution may experience a few seconds delay. Such delay can add up with time and the task schedule may experience a noticeable drift from its original schedule.
The issue was caused by a delay in scanning logic that looks for ready-to-run tasks, in combination with the fact that such delay was included when calculating the next execution date. This issue had been fixed and you should now expect no more than 1 second delay for your task executions across all schedule modes (interval-based and cron-based), with the drift behavior eliminated.
Thank You
Thank you for reading! Our goal is to keep improving our product to provide you a better user experience for scheduling HTTP requests while maintaining our service availability and reliability. This includes minimizing regression along the way by enforcing comprehensive quality control coverage. As always, if you have any feedback on our product and features, please contact us at support@ihook.us, we look forward to hearing from you!
We updated the history chart UI with a dropdown list to make it easier for users to select common metrics such as response time and status code. Of course, you can select the response body option in the dropdown, where a search box will appear for you to draw charts for certain properties from the response body.
This change makes it easier for new users to explore the feature and also makes the chart section more concise. And don't forget that you can add bookmarks for your charts for easy future access. For more details, please see our doc page.
Response Time Metrics:
Response Body Property Metrics:
Follow HTTP Redirect
On the task execution front, we added a setting to allow tasks to automatically follow HTTP redirect when issuing a POST request. Before this enhancement, iHook only follows redirects for non POST requests, as specified in HTTP RFC 2616. Now you can relax the restriction by enabling the task setting under the Advanced Option section.
HTTP Request Header Override
When iHook sends HTTP requests, a couple of headers such as User-Agent and Accept are added by default to maximize the chance for a request to succeed (You can inspect each request's header information under the History section).
Now you can override those pre-defined header values. For example, you can assign a browser User-Agent value such as Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.95 Safari/537.11 to better simulate browser requests. The override will be case insensitive.
Auto Disabling
If a task could not receive a response from the remote side after 15 seconds, and if this happens 3 times in a row, iHook would disable the task and notify you via email. Now we are extending this behavior for tasks with 4xx and 5xx response status code.
We realize that most users would end up with a 2xx status code if their HTTP requests were to achieve something meaningful. With this change, it would allow us to better allocate our task scheduling resource and notify users when requests receive bad status code.
Surely some users would still be interested in 4xx and 5xx status code. To avoid auto disabling, you can create notification rules that check for status code. That way we would know that you are making a conscious decision about the expected HTTP response status code for a task. As long as such rules are present, no auto disabling would occur on 4xx and 5xx status code.
Thank You
Thank you for reading and thank you for your continued support for iHook! As always, if you have any feedback on our product and features, please contact us at support@ihook.us, we look forward to hearing from you!
We are super excited to announce our new task execution data visualization component!
Under the History tab, you can find a new chart component, which you can use to draw a time chart to understand the trend of task execution data such as response time:
What's more exciting is that if your task returns a JSON response body, you can draw a time chart for those JSON properties:
The chart allows you to aggregate a view of a specific data point across multiple task executions, without having to inspect each execution detail.
One common use case of the chart is system monitoring. If you have a task that returns system metrics data in JSON format, you can create charts that show the trend of those data points such as free memory and CPU usage. For your favorite charts, you can save them as bookmarks under the search box, which is just one click away from bringing those charts back in the future.
You can find more instructions about the feature here.
Notification condition for response headers
We enhanced our notification condition component to support checks around response headers.
One interesting use case for this is to detect CORS misconfiguration for static website assets hosted via S3 and CloudFront.
If you host your website images on AWS S3 and put it behind CloudFront CDN, and if the CloudFront distribution is misconfigured, client browsers will have trouble accessing the image with the following error:
Access to image from origin has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
The tricky part is that the missing Access-Control-Allow-Origin header issue only happens occasionally. Setup an iHook task that checks the header value would help identify the issue and help confirm the fix of the issue.
Accessibility enhancement
On the UX front, we added a shortcut for saving the task edit form and notification edit form. Now you can use Ctrl + Enter or Command + Enter (for macOS users) to save the form. We believe this will help make the form editing experience less frictional, hope you enjoy it!
Doc search
We added search capability for our doc and blog sites. A huge shout out to Algolia's DocSearch program, with their help we were able to provide an awesome search experience. If you are considering adding a search feature to your doc site, we highly recommend this program.
It's worth mentioning that if you are considering building your doc site from scratch, take a look at Docusaurus, that's the open-source framework we use at iHook. It's markdown based so the editing experience is pretty smooth. And it has pretty good extensibility - adding a search feature is as simple as adding Algolia's API key and index name in the project config file.
Thank You
Thank you again for your continued support for iHook! As always, if you have any feedback on our product and features, please contact us at support@ihook.us, we look forward to hearing from you!
A lot of worldwide popular products are heavily adopted by their internal team, such as Slack and Notion. In this article, we'll talk about how we use iHook in our daily operations.
Email Notification Volume Monitoring
Email notification is a critical component at iHook, to ensure the component functions properly, we constantly monitor the email notification traffic to identify abuse. There are two ways to approach this: one is to generate a log each time an email is delivered, and use analytics solutions such as Splunk to fire an alert if the email traffic exceeds a certain threshold; at iHook though, we realized that we could achieve this by setting up a scheduled iHook task.
The problem we are solving here is essentially counting email delivery events. So we created a database table that stores all such events.
The schema is pretty straightforward but allows us to store user account id and additional data if we want to investigate further about the event. Whenever an email is delivered, we will create an event of type email.send.success and persist it in the database.
Then we created an API endpoint for us to count the events based on event_type and time range:
Request:
GET /api/v1/events/count?eventType=email.send.success&sinceMinsAgo=5
Now we just need to create an iHook task that monitors the result of this API, and notify us when needed. Here's the task configuration:
Every 5 minutes, the task issues an HTTP request to our event count API and then evaluates a notification rule that checks the count property of the JSON response, when the count exceeds 5000, we will be notified via email.
Note that you may set up additional notifications via other channels such as SMS, Slack, and HTTP, in case the primary channel failed to deliver. Using the same pattern, we created more tasks to monitor events such as task execution failure and user account upgrade/downgrade.
The API runs efficiently since we've indexed the event_type db column. And this approach freed us from uploading log entries to a log analytics solution for monitoring, and thus reduces our cost.
User Growth Tracking
We feel super excited when a new user joins iHook - it's a validation of our product value and means more people could potentially benefit from iHook's automation capabilities. To better monitor user growth, we created a daily iHook email notification task.
iHook uses Okta for identity management, which means most iHook user profiles are stored and maintained at Okta. To retrieve iHook's total user count, we created a daily task that monitors Okta's user API.
Here's the task configuration:
Once everyday, the task issues a GET request to Okta's user API, which returns a list of active user object in JSON format, and then evaluates a notification rule that checks the user list size via the length()JSON path expression, when it changed from its last evaluated value, an email notification will be sent.
Note that the email template contains a template variable${condition.evaluatedSourceValue} that would turn into the actual total user count when the emails are delivered.
The task saved us from implementing a custom notification logic in the user registration flow, and it had been working great so far!
Our focus in July was mainly on service hardening, along with a handy product update around notification rule.
Product Updates
This month we added a new property value comparison rule for notifications - value has changed. This rule is helpful for users who want to be notified when a task's property value has changed from the last execution's value, and not be notified when the property value remains unchanged.
Before this change, users who are tracking a constantly changing property value has to manually update the target value in the notification condition form, to keep the monitor rule relevant, which can be tedious.
For example, a website owner wants to get notified when a new user registers for his website. Previously he can achieve this by creating a scheduled task that calls the website's user count API, and set up a notification rule like below:
This way the user can receive a notification once the count increases. Though he will have to maintain the Target Value to keep the notification rule relevant. Now with the new change, he can use the value has changed option, sit back, and let iHook task do its work:
Infrastructure Updates
This month we added a secondary email vendor to ensure email notification deliverability in case of primary email vendor outage. On July 28th, our primary email vendor was experiencing a major service outage where email deliveries were significantly delayed or rejected for 6+ hours. Fortunately, we've had our failover mechanism in place and delivered our email notifications via the backup vendor.
Infrastructure redundancy is very important to ensure service availability. We'll keep investing in this area to make our service more resilient. Next, we'll explore providing backup service for the following components:
Primary database
Cron scheduler
Task worker
SMS notification service
Server monitoring tool
Ops Updates
On the ops side, to better protect us against hacking activities, we revisited all of our cloud infrastructure vendors' account security settings and enabled MFA for those that haven't yet. This would add a bit more friction during login, but the security benefit is well worth it.
Also, we updated our system health check API permission checking logic, such that we can use less privileged API keys in our 3rd party monitor tool, to minimize the security impact in case our API credentials get leaked.
Thank You
Thank you for reading, and thank you for your trust with iHook. If you have any feedback, please don't hesitate to contact us at support@ihook.us, we look forward to hearing from you!
It's time again for the monthly release update! We have a couple of exciting features rolled out in June.
Product Updates
On the task history side, we added pagination support. Before this change, users can only view the most recent 20 task execution results (response headers, response body, etc.). When a user configures a task with a 1-minute schedule, an execution result would become inaccessible 20 minutes after execution. With this change, users would be able to view older execution results - Free plan users can now view the most recent 200 task execution results for each task, and Hobby plan and Business plan users can view recent 2,000 and 20,000 task execution results respectively.
This feature is helpful for use cases with a frequent schedule such as service monitoring. Let's say you have an API that returns all the failed payment transaction detail for the past 5 minutes. You can set up an iHook task to call this API with a 5-minute schedule, create an email notification with a JsonPath rule "failed payment transaction count greater than 0". And you should be able to review the response body value in the task history section, even a couple of hours after you receive the email.
On the notification side, we added support to send notifications when tasks fail to complete, for scenarios like request timeout. Before this change, users will only be able to receive notifications when the target have responded, i.e. returns an HTTP status code. Timed out tasks will fail silently. With this change, users who are cautious about task deliverability can create notification rule that checks against HTTP status code to detect task execution failures. For example, a notification with rule "Status code not equal to 200" will be triggered when such task failure occurs:
On the UX side, we updated the dashboard style with a navy navbar, so the style is consistent with other iHook properties such as Doc and Blog. We also introduced more side spacing to the dashboard page, in the hope that a more compact layout would help users observe more content with each glance, and reduce friction when navigating the page.
Infrastructure Updates
On the UI side, we trimmed our homepage's static assets (JS libraries, CSS style files, font files) to a total of 844 kB, with most of them served on AWS CloudFront CDN, our users with a reasonably fast internet connection should expect the homepage to complete loading within 500 ms.
Thank You
As always, thanks for reading, and thanks for your continued support of iHook. We will continue our hard work to provide a reliable service. Our goal is to allow people to perform their daily tasks more efficiently, by leveraging the power of cloud services. We are excited about the opportunities in front of us.
Hope all is well around this special time. It has been a fruitful month with enhancements on the product side and infrastructure side.
Product Updates
We added full UTF-8 character support when evaluating tasks' response body. If your target's response body contains characters such as a pile of poo 💩, and you want to set up conditional notifications around those data, you can do it now. We should have supported this from day one, but due to an improper database charset configuration, we ended up supporting a much smaller set of UTF-8 characters (more details see: https://mathiasbynens.be/notes/mysql-utf8mb4#character-sets). So my apologies to those who send requests to emoji rich websites, and have seen message Error saving response body in your task execution history. This issue had been fixed.
The charset configuration update requires a database migration. It was the most time consuming migration we've done since it needs to migrate one of our largest database tables, which stores tasks' response body. And yes, every single row. Service availability has always been our top priority. To make sure we have a smooth migration in production, we stress-tested the process in our stage environment, which has an identical database setup as our production environment. The migration took 3.5 minutes for 8000+ rows that store 3 GB response body in HTML format, this all happened on an idle server without disrupting any core services.
We also introduced a task retry mechanism. Web tasks that timed out will be automatically retried one time before marked as failed. This is particularly useful when the HTTP target is served outside of North America, where we host our servers. This would increase the success rate for tasks with those HTTP targets. Eventually, we will deploy servers in more geographic locations to reduce failures due to network connectivity issues. So far, our web requests to European and Asian domains have enjoyed a pretty high success rate, but we'll continue monitoring our success rate to help decide when to start expanding our server regions.
Infrastructure Updates
We optimized our response body storage logic. This dramatically reduced the database footprint when response body remains the same for a web task. This helps iHook scale as our user base keeps growing, and paved the way for us to support much more than 20 task execution history we support today, which is far from enough for users who trigger once per minute and want to review task execution detail a couple of hours earlier.
We refactored the way user authentication data is stored and accessed, which reduces the database queries needed to serve a client request. Users should experience slightly faster loading speed when accessing various functionalities in the dashboard. We also refactored the logic that connects the scheduler and the HTTP request worker, which dramatically reduces the amount of database write transactions. This helps reduce the delay between a web task's scheduled execution time and actual execution time.
Thank You
Thank you for reading! And thank you for your trust with iHook. It's encouraging to see new friends joining our community each week, and to see that iHook's automated web tasks are making your life a little bit easier. In return, we'll keep working hard on delivering high-quality features, that provide great user experiences. Stay safe!
